Setup and Teardown test database in Jest results in database action errors

[feclist]

We're looking for some guidance on testing our application with WatermelonDB. Our understanding is that we'll need to have a test database with setup, seeded data and tear down.

After a couple days of experimentation, here are a couple of related issues we are stuck on. Would appreciate any thoughts you have on them. (The test setup is jest with enzyme):

1. beforeEach and afterEach database actions result in ... can only be called from inside of an Action. See docs for more details.
   An example of the beforeEach code with the database setup:

const adapter = new LokiJSAdapter({
  dbName: 'test',
  schema
})
const database = new Database({
  adapter,
  schema,
  modelClasses: [TabModel, File],
  actionsEnabled: true
})

beforeEach(async () => {
  // Prepopulate the database with data
  await database.action(async action => {
    file = await database.collections.get('files').create((file: File) => {
      file.name = 'test.csv'
    })
    await action.subAction(async () => {
      tab = await database.collections.get('tabs').create((tab: TabModel) => {
        tab.fileId = file.id
      })
    })
  })
})

Results in the error Collection.create() can only be called from inside of an Action. See docs for more details. on runtime. A similar thing happens when I try to clean up the database after the code has run await database.action(async () => await database.unsafeResetDatabase()).

In general, we've noticed this behaviour pop-up on occasion inside the app, without a discernible pattern. Have you seen this kind of thing before?

2. withObservables (as a HOC) using Enzyme's .dive() results in a TypeError: ShallowWrapper::dive() can only be called on components

We have a <Tab> component wrapped in withObservables HOC. For testing in enzyme, we need to call .dive() on the HOC to go down one layer and render the children. Here we get the above error. We've tested this with other HOCs without an issue. (Appreciate this has to do with Enzyme too.)

3. useDatabase context hook is causing Enzyme problems.

This is more of an issue with Enzyme rather than WatermelonDB, but we would like to get some insights on how we could work our way around this. We have found this comment seemingly working around the useContext problem. We've tried a similar approach, but that brought us to another error where it seems we can't mock the return value of useDatabase. (Tried this with Sinon.stub, Jest.spyOn and Jest.fn)

If any testing experiences / insights can be shared when it comes to WatermelonDB that'd be dearly appreciated!

[radex]

I don’t know much about Enzyme, so I don’t know how to help with the withObservables problem (although I suspect it has something to do with the fact that it’s asynchronous, and so you might only get a full render on the second render.

But the issue with actions is very strange. I suggest you follow the code in Database.action — it sets a flag and then unsets it after the action is complete, so you should be able to figure out what went wrong where

[feclist]

Thanks for the quick reply! I will definitely look into the Database.action code, hopefully I can find the solution to the problem there.

One detail I forgot to mention is that this Collection.create() error only started showing up after I deleted my node_modules folder and re-ran yarn. The same error but then for unsafeResetDatabase I got was already there. Maybe this information might give some insight as to where this problem comes from.

[radex]

no idea — the only thing that comes to mind is that you downloaded a newer version of watermelon which has some sort of a regression, but I haven’t seen iissues of that kind on our project.

[feclist]

Alright, so after doing some digging I figured that it has to do with the asynchronous nature of WatermelonDB. I set up the database and adapter outside of async functions, not so sure if that is exactly why it ended up showing me errors. Would need to do some more research into that.

What I found and suspect is that the action error is functioning more as a catchall error. When the adapter/database hasn't been initialised yet and you start running actions on top if it, it throws the action error. It seems more like the action can't be executed yet since the database is not ready to accept any traffic at that state. Correct me if I'm wrong on this hypothesis!

This would also explain why I started getting similar errors in the app itself, maybe after hot reloads the database gets in this funny state where it can't accept any actions causing the overall action wrapper error to be thrown.

[radex]

What I found and suspect is that the action error is functioning more as a catchall error. When the adapter/database hasn't been initialised yet and you start running actions on top if it, it throws the action error. It seems more like the action can't be executed yet since the database is not ready to accept any traffic at that state. Correct me if I'm wrong on this hypothesis!

Hmm, it's possible, but that would be a bug. While the database sets up asynchronously, it should be able to accept actions immediately (they should just queue and execute in order when ready)

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.