Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

But then how do you deal with unique constraints or things like upserts? If I want to add 10 entries, then I need to know that all have been added and not pre-existing, or else the code for adding new entries doesn't actually get tested. Or you end up with spurious test errors if insertion fails due to duplicates.


> But then how do you deal with unique constraints or things like upserts? If I want to add 10 entries, then I need to know that all have been added and not pre-existing, or else the code for adding new entries doesn't actually get tested.

Then your test code needs to take into account the current state of the database when creating input data for the code under test. It is more complicated than with a know start state where you can pick fixed data, sure, but it's doable.


> Then your test code needs to take into account the current state ... [ etc ]

... and you're on your way to writing an application, not a test!

Tests should be as simple as possible, and a clean slate goes a long way toward that.

A test should be riddled with as few "needs to do" responsibilities as possible while still achieving the intended coverage.


If you want to test that “it adds X entries” then write the test to add X entries from a clean state, then add another X entries and check it is done correctly. You don’t need to rely on a dirty start state to do that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: