3 ms·
I did this, and then switched back to just running the code on a test database. I found I was writing two sets of tests: one that tested the code to see if it i
by marcus_holmes 7y ago
I did this, and then switched back to just running the code on a test database. I found I was writing two sets of tests: one that tested the code to see if it injected the right parameters into the SQL, and another to see if the SQL worked. It just got easier to test them both together.
- dcolkitt 7y agoThere are tradeoffs to this approach. When the tests break it becomes a lot harder to triangulate the origin of the problems.
- runeks 7y agoI don’t buy this argument. Once you know there’s a bug, you will definitely want to write more tests, in order to find the cause. But always writing a lot of tests, which are only usable in case you find a bug, seems like wasted effort to me. If you need to triangulate the origin, do that when it’s necessary (i.e. when your broad test fails) and not all the time.
- GordonS 7y agoI prefer to just runs tests using a real database too. They might not complete as fast as mocked out ones, but they give me much more confidence of correctness, and still complete in milliseconds.
- breischl 7y agoThis can become a challenge when you want to scale a dev team. You either have people conflicting in the DB, or each dev needs to set up a local DB and deal with DB migrations. Containerized DBs help with this to some extent, but it's still a maintenance headache. There's also a tradeoff around testing error states, but that can be a wash. Some errors are easier to create with a mock, some are easier to create with the actual driver.