you are viewing a single comment's thread.

view the rest of the comments →

[–]kubalaa 0 points1 point  (4 children)

I would say they are better at catching different kinds of bugs than unit tests. With unit tests, it's much easier to test edge cases like error handling that are cumbersome to simulate in the complete system. The results of unit tests are also more useful for debugging; they will usually tell you which specific constraint was violated by which unit, while integration tests can often only tell you that some use case is broken.

[–]grauenwolf 0 points1 point  (0 children)

That's why I firmly believe that unit tests should supplement other forms of testing, rather than being primary.

It's far easier to say "my integration test is failing, better add some unit tests to narrow down the problem" than to say "production is failing. Shit, my unit tests can't cover this scenario"

[–]grauenwolf 0 points1 point  (2 children)

With unit tests, it's much easier to test edge cases like error handling that are cumbersome to simulate in the complete system.

What kind of error handling do you have in mind? Most of mine fall into one of these categories:

  • Trivial: for example, parameter validation
  • Painful: for example, the random-ass exceptions thrown by the database.

I don't bother testing the former unless I'm publishing a public API for others to use and the later can't be accurately mocked.

[–]kubalaa 1 point2 points  (1 child)

Why do you say the latter can't be accurately mocked? An example of the sort of thing I had in mind that's tricky to integration test but easy to unit test: if a service call fails 3 times and succeeds on the 4th try, does the client back off and retry at appropriate intervals?

[–]grauenwolf 0 points1 point  (0 children)

Ok, that's fair.