Anyone tried dynamodb local to run tests with jest...
# help
s
Anyone tried dynamodb local to run tests with jest? I'm trying to use this one: https://github.com/shelfio/jest-dynamodb but SST seems to not allow configuring Jest presets
f
Hey @Stan, lemme get some help
@thdxr are you familiar with jest presets?
g
is there any benefit using sst to use a dynamodb local instance instead a remote one?
s
At the moment I'm still trying to evaluate. I'm kind of used to tdd way of dev, and I would like to be able to test my dynamodb related code while I'm writing - with dynamo its not always obvious what will be the response, so I prefer to test against dynamo during development instead of mocking. I'm also having now the test which connects directly to remote dynamo. The thing is, I would like to create the table before the test, run test that operates on the table and then delete the table - this way I'm targeting to be able to have one table per test, so I can run them in parallel. Now the benefits of local - same would be faster, you don't need to wait until the table is in Active state, and there is almost no delay on GSI (no consistent reads on GSI, so in test you need to wait)
I've read some discussions here already, I heard some folks are deleting all the records from the table using scan first, which is probably faster, but then probably not so easy to run tests in parallel
t
Hey I actually used local dynamo for tests
s
Did u download the jar manually, run it and then just connect from jest, or you are using some package like dynamodb-local or jest-dynamodb to automate that?
btw, this is the error message I get when I follow this docs https://jestjs.io/docs/dynamodb
t
I ran it through docker, didn't use any package just set the environment variable for it to look locally. Ultimately I abandoned it and just use a cloud dynamo table
I also don't use SST test I call jest directly
s
Thanks @thdxr, I actually might end up doing the same thing
I've found a workaround to make this working with standard SST test setup - sharing here in case anyone else would be interested. Instead of {"preset": "@shelf/jest-dynamodb"} suggested in docs, use this:
Copy code
"jest": {
    "globalSetup": "./node_modules/@shelf/jest-dynamodb/setup.js",
    "globalTeardown": "./node_modules/@shelf/jest-dynamodb/teardown.js"
  },
t
Nice
We have to look at our jest implementation deeper. Shouldn't have to work around it
s
Actually, I think there is not much to do. I had a look on the file of the preset, and it seems it's just simple js object that simplifies configurations with some... presets 🙂 Now seems more reasonable that multiple presets are not allowed
Copy code
module.exports = {
  globalSetup: resolve(__dirname, './setup.js'),
  globalTeardown: resolve(__dirname, './teardown.js'),
  testEnvironment: resolve(__dirname, './environment.js')
};
Finally i was able to compare timing on both approaches. I run same jest test: -create table -create entity -query main table -query gsi -some expects -delete table Remote dynamo needs approx 25s, local dynamo needs approx 5s to run such test.
t
Hm I don't think I saw as much of a gap
Oh you're creating the table in the test?
s
yep, and this is the most time consuming
t
that makes sense