This is one of those things where there is no general consensus on the "correct way". Some people will say to stub the database calls (i.e. - your query functions), some will say to use a test database and rollback the transaction after each test runs, some will say to use a set of fixtures to prepopulate the database, some will say to use factory functions to insert records rather than use fixtures... I think you get my point...
The way I'm currently doing it (which could change, but it works for me for now) - is using a test database with a set of fixtures/seed data. I use docker-compose which makes it easy to spin up test databases using the same Docker images/configurations as you'd use in production. So my database layer unit tests talk to a real database. IMO it's best that this database be a real one and not an in-memory database. You want your DAL tests to mimic what will be run in production as closely as possible. If you're concerned that using a real database will slow your tests down, check out this article which has good recommendations for speeding that up significantly: pythonspeed.com/articles/faster-db...
A software engineer interested in solving real problems, developer productivity & learning languages for fun. Primarily working on Node.js, React & databases. Current Interest: Rustlang
This is one of those things where there is no general consensus on the "correct way". Some people will say to stub the database calls (i.e. - your query functions), some will say to use a test database and rollback the transaction after each test runs, some will say to use a set of fixtures to prepopulate the database, some will say to use factory functions to insert records rather than use fixtures... I think you get my point...
The way I'm currently doing it (which could change, but it works for me for now) - is using a test database with a set of fixtures/seed data. I use docker-compose which makes it easy to spin up test databases using the same Docker images/configurations as you'd use in production. So my database layer unit tests talk to a real database. IMO it's best that this database be a real one and not an in-memory database. You want your DAL tests to mimic what will be run in production as closely as possible. If you're concerned that using a real database will slow your tests down, check out this article which has good recommendations for speeding that up significantly: pythonspeed.com/articles/faster-db...
Thanks a lot. That's what I was looking for