Scaleable way to manage integration tests?

I’m working within a Node.js application with GraphQL endpoints. I’m mainly using Jest for unit tests, but have started to write integration tests for CRUD on MongoDB collections to cover complex, multi-collection, multi-db, cascading ops in my resolvers.

I currently have a few strategies for writing integration tests, but want to have them vetted by the community and hear other options before I choose a strategy to run with. At the moment, I’m running these tests locally, but would like to run them continuously with something like Github actions sometime in the near future.

Approaches tried so far:

  • Run each test against a “staging” cluster (clone of our production dbs) in a transaction and purposefully throw an error at the end to roll back all changes.
  • Create TEST_collections to insert and manipulate mock data to test CRUD, deleting the collections after each test to clean things up.

I’m also deciding on whether or not to setup a mongodb-memory-server for each test to allow parallel testing and faster overall performance.

Hello @Matthew_Van_Dyke! Thanks for your awesome question!

Now, it depends on your definition of what an “integration test” means to you (people have very strong opinions on this subject :stuck_out_tongue:) However, traditionally, when writing integration tests that touch a DB in some way or another, it is best practice to mock the actual database call. The purpose of mocking is to skip the complexity and unit test own code.

There are mock libraries built into Jest.

Does this help?