Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
mock s3 tests
See original GitHub issueThe 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, which uses sinon stubs.
cc @springmeyer
Issue Analytics
- State:
- Created 5 years ago
- Comments:7 (6 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
Ah, okay. In this case node-pre-gyp primarily uses both http and aws-sdk to interact with AWS. http for GET and aws-sdk for PUT/DELETE/LIST.
Diving into these tests has left me with some large-scale refactor desires. Opened a ticket in https://github.com/mapbox/node-pre-gyp/issues/392 to discuss this further.