2

I'm wondering if it is common practice to use an in-memory database for a test environment, instead of MySQL (that has to be used for development/production).

If it makes sense, how do I set this up?

I think I can create config/test.json as shown in their chat example, my app.js still requires Knex though.

Should I do something along the lines of

const knex = (NODE_ENV !== 'test') ? require('./knex') : undefined;

and then configure it only if knex !== undefined?

If I do so, all my models have to be set up twice (once for Knex, once for testing without it).

What is the right/standard way to go about this?

EDIT:

As suggested below, I use a different schema for testing. This is done by declaring a different connection string in config/test.json.

This question is solved, thank you!

houtenjack
  • 43
  • 9
  • Use mocks over different database. – Ayush Gupta Oct 04 '18 at 07:22
  • How would I do that? [their docs](https://docs.feathersjs.com/guides/chat/testing.html#testing-services) suggest that I have to source the actual application, which internally sources Knex – houtenjack Oct 04 '18 at 07:25

1 Answers1

2

if it is common practice to use an in-memory database for a test environment, instead

Sadly it is a common practise, but not particulary good one. When you use different database for testing and other for production your tests are actually not testing that the application code is working in real database.

Other negative effect is also that you cannot use special features of any of those databases, but the code would have to use that subset of DB features, which are supported by both of the databases.

I would ran all the tests with all the supported real databases to actually make sure that code works on every targeted setup.

ps. Someone was telling to use mocks for abstracting database... that is another bad practise. They work for some small part of testing, but in general case you need to run tests against real database to be sure that code works correctly. Important thing is to setup tests in a way that you have a fast way of truncating old data and populating new test data in.

Mikael Lepistö
  • 18,909
  • 3
  • 68
  • 70
  • Thank you, I am now using a real database, it is just a different schema from the development one (so I can store users and other data without seeding every time). I'm creating actual data during the tests, then deleting it all in `after()` hooks, so that I don't get errors when running the tests more than once. – houtenjack Oct 09 '18 at 07:02