3 ms·
The best way to do db testing is with an empty db and in a specialized dao test. Try to make these dao tests non-overlapping so that the dao test is the only t
by narrator 11y ago
The best way to do db testing is with an empty db and in a specialized dao test. Try to make these dao tests non-overlapping so that the dao test is the only test that hits that part of the schema. Also, if your dao tests are the only thing that hit I/O you can safely do all the other non-integration tests concurrently.
Service layer tests should have mocks of the dao and web service calls. You should do most of your testing here and with unit tests for tricky algorithms.
Integration tests should hit the full stack, but those should run on a continuous integration server asynchronously and also take place in their own empty database.
The key to dao and integration testing is the empty database. Don't let it fill up with test crud between tests. PostgreSQL is pretty fast when your test db only has a couple of rows.
- raducu 11y agoThis is by far my favorite way to test; not something I invented but something I picked up start with an EMPTY DATABASE (with tables setup), then every test: begins a transaction,asserts the db is empty, sets up the data (via factories and DAOs), performs its queries (via DAOs) rolls back the transaction for the next test.
- lmm 11y agoIt's a fast approach that gives some test coverage, but some of the most important things to test are around the interaction of multiple transactions, which you can't do if you're using a single big transaction to run your test.
- mattmanser 11y agoAn empty DB? Some major bugs are caused by people not testing their code with enough data.
- EugeneOZ 11y agoNot production DB, obviously :) Generate data before tests, collect list of created records during tests, remove collected items after all tests - if DB is not empty after it, you can see something unexpected has happened. If it's not possible to collect records (because of too opaque ORM), just flush DB.