mock s3 tests
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 1.2k
- Forks
- 271
- Avg merge
- 23h 40m
- Merged PRs (30d)
- 2
Description
The tests that use s3 to put/update/delete objects are prone to race conditions if the same tests are being run from multiple places (i.e. pr & push builds on travis). This leads to unexpectedly flopping tests and solving with a retry, which is a bit cumbersome. Example errors:
```
404 status code downloading tarball https://node-pre-gyp-tests.s3-us-west-1.amazonaws.com/app3/v0.1.0-dev.4/node-v51-linux-x64.tar.gz
```
In order to run tests reliably, we can mock out s3 functions and their responses and assert specific parameters were called. Let's have a look at [mock-aws-sdk-js](https://github.com/mapbox/mock-aws-sdk-js), which uses sinon stubs.
cc @springmeyer
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Locate the tests that put, update, or delete S3 objects and review mock-aws-sdk-js for its Sinon-stub approach. Replace the S3 interactions with mocked functions and responses, asserting their parameters so the tests remain reliable when run concurrently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, javascript, node.js
- Domain
- cloud, testing
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100