Integration verification module. Tests various integrated usage scenarios.
| type | description |
|---|---|
| single client | Isolated single client to server feed upload and bundle |
| multi client | Simultaneous multi client to single server feed upload and bundle |
| sinks | Tests for sinks other than mem sink |
| scenario | Setups for more realistic real world scenarios |
These tests verify simple correct behavior between a single instance of the asset-pipe-client and a single asset-pipe-build-server.
These tests verify more complex behavior between a multiple instances of the asset-pipe-client and a single asset-pipe-build-server.
Tests for both the google cloud storage sink and the file system sink. The memory sink is tested pretty thoroughly as part of the test types so is not re-tested here. The aws sink is not tested as it is not yet published to npm.
These involve simulating a single coordinating server and multiple dependents. Dependents upload their js and css assets to the asset pipe build server. The coordinating server then also uploads its js and css assets to the build server before finally bundling everything together. Server latency is randomly introduced during the process.
- Provide test coverage of the integration of the various modules in the asset-pipe project
- Give early warning if one of the asset-pipe modules publishes changes that break the integration of the project as a whole
Dependencies are set to latest and package lock is ignored. CI cache is not used. All this to ensure than when a test runs it runs against the latest versions of the asset-pipe-client and asset-pipe-build-server. Greenkeeper is also used to trigger runs whenever one of the asset-pipe modules is publishes a new version.
The contribution process is as follows:
- Fork this repository.
- Make your changes as desired.
- Run the tests using
npm test. This will also check to ensure that 100% code coverage is maintained. If not you may need to add additional tests. - Stage your changes.
- Run
git commitor, if you are not familiar with semantic commit messages, please runnpm run cmand follow the prompts instead which will help you write a correct semantic commit message. - Push your changes and submit a PR.
Some tests (google sink tests) rely on credentials for google cloud storage. These will run correctly on CI so you may need to rely on those if you don't have access to our travis setup.
Credentials are encrypted using travis cli. https://github.com/travis-ci/travis.rb#encrypt-file which should also allow you to decrypt a copy for local use if you have access to our travis account.