Open SET001 opened 6 years ago
@SET001, due to the current implementation of the dynamo emulator, which uses the slow to boot JVM, I have found that the initial run of tests fail, and the second run of tests will succeed. We are looking into using nailgun.
To be clear -- are tests passing for you?
tests from appsync-simulator-test-example
are passing, yes:
set@set-home ~/www/cloudbeds/appsync-serverless-emulator-example $ npm test
> appsync-simulator-test-example@1.0.0 test /home/set/www/cloudbeds/appsync-serverless-emulator-example
> jest --detectOpenHandles
console.warn node_modules/ascoltatori/node_modules/node-uuid/uuid.js:48
[SECURITY] node-uuid: crypto not usable, falling back to insecure Math.random()
PASS __test__/graphql.test.js (18.644s)
graphql
✓ None & Lambda examples (418ms)
✓ subscription / mutation / dynamodb (196ms)
Test Suites: 1 passed, 1 total
Tests: 2 passed, 2 total
Snapshots: 0 total
Time: 19.46s, estimated 20s
Ran all test suites.
However when I'm was trying to run tests from my project I was getting few errors without any description. Wrapping state.server = await create();
in try/catch with output of error message in console would save many time for me. This is what this issue about.
@cbaron is it possible to run local dynamo server and use it for each subsequent tests runs, instead of rerun dymano emulator each time?
@SET001 -- its possible, but we prefer to utilize a separate instance for each set of unit tests so that they can run in parallel in jest without interfering with one another.
its possible
how is it possible? any example?
but we prefer to utilize a separate instance for each
are there any reason you call those tests a unit
? an't they integration by the nature?
@SET001 You are welcome to write your own test implementation which calls create
once. Certainly, we will take your request in consideration.
are there any reason you call those tests a unit? an't they integration by the nature?
Not exactly sure what you're asking. At the moment, I refer to an it
block as a unit test. Currently, our organization prefers to write unit tests wherein a server can be spun up, then destroyed for a block of unit tests so that many blocks of unit tests can run in parallel at the same time without collisions.
There are a lot of things that may go wrong while executing
create
in emulators jest beforeEach block. I propose to wrap it intry/catch
block something like this:it helps to understand what is going wrong