Integration tests implementation

Questions

I don't know how to write other types of integration tests?

How do I write non-bigbang types of integration tests?

Should integration tests be equal to unit tests meaning same number of tests, but testing without mocks? Or should these tests test something completely different?

Could anybody provide any information how to do this (if at all) or whether it's actually feasible doing it?

I suggest doing these:

unit tests / must not hit any external resource
focused integration tests (I guess that'd be bottom up). You should have code that is very close to the external resource, and the sole responsibility of it is integrating with it. Don't try to unit test those classes, instead do very focused tests that hit the real resource and don't have to deal with the rest of the logic in your system. Keep this integration classes as thin as possible
full system tests (I guess big bang). I mean with the UI and everything (or API if that's your endpoint). Make sure you cover as much as possible with the previous tests, and this is more like simple checks the underlying pieces are hooked appropriately.

Depending on your system, you may or not want to complement 3 with integration tests at the top level of the code, but without involving the UI. Regardless of which option you take, make sure to have more comprehensive coverage through unit & focused integration tests, as testing various behavior at the top level have a complexity level that can get out of control very quickly.

Should integration tests be equal to unit tests meaning same number of tests, but testing without mocks? Or should these tests test something completely different?

As I mentioned in 1 & 2, its best when those test different things. This depends on the system, but I'd usually expect the amount of unit tests to be a few times the amount of integration tests. For full system tests, make sure you have enough so that you can tell all the pieces were hooked correctly, but not so much that it becomes too complex to test each scenario.

Ok. I get you. And it makes a lot of sense. If I have successful unit tests all the way down to repositories, then I could do integration tests on repositories that they do work correctly on DB and **assume** other units from this bottom-up would work just as well as they did in unit tests. **Is that what you're implying?** (BTW: +1 for a very clear answer that points in the right direction)

Robert Koritnik 2010-09-30 18:18:51

yes, it works best if the code is done by following SOLID and DRY. Remaining issues tend to be UI or something that wasn't hooked correctly. The later is usually caught very quickly in system tests. There might be v. specific scenarios where the above misses, but full coverage its not possible. This strategy has a lot more chances of increased coverage and testing combinations that would otherwise be too many or too cumbersome to do at a higher level. Finally, the missed scenarios are still likely to be missed with the other strategies, like the weird char that ends up going to a mail sender.

eglasius 2010-09-30 18:34:55

@eglasius: I find it interesting that you're abbreviating a 4 letter word with 2 characters (v )** At first I thought these Vs meant something else than just *very*.

Robert Koritnik 2010-09-30 19:39:15

lol, thx for letting me know / edited it

eglasius 2010-09-30 19:47:14

ansaurus

tags:

views:

answers:

Integration tests implementation

Questions

related questions