Timeline for Is it sufficient to use acceptance and integration tests instead of unit test?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 14, 2014 at 10:25 | comment | added | twilker | @gbjbaanb I do not like to write integration tests which covers a huge amount of code. They are most brittle and hard to debug. In my case my integration tests concentrate on one aspect of the program. Therefore I have many of them. But that is easy to write when using a BDD approach. | |
| Jan 14, 2014 at 10:23 | comment | added | twilker | @Michael When I use tools like Cucumber or SpecFlow correctly I can create integration tests which also tests exceptions and extreme situations as fast as unit tests. But I agree if one class has to much permutations I prefer writing a unit test for this class. But this will be less often the case than having classes with only a handful paths. | |
| Jan 13, 2014 at 18:43 | comment | added | Michael Shaw | Two bugs cancelling each other out is more common than you might think, especially if both components were written by the same developer with the same misunderstanding of the system. | |
| Jan 13, 2014 at 17:46 | comment | added | gbjbaanb | Absolutely, but that's why I prefer to use both - it means I don't have to spend all day writing a thousand unit tests, I use them for the more complicated bits only, and use integration tests for the rest, its a trade off between dev time and risk. I never found unit tests to catch all bugs anyway so I don't miss the 'gamefication' of using them so much. And besides, you still need integration style tests even if its just for performance testing. | |
| Jan 13, 2014 at 16:42 | comment | added | Michael | Oh I agree that integration tests CAN exercise bad data and how faults are handled, my point was that in my experience, that isn't what integration tests do - YMMV though - I'd also say that hitting every exceptional combination in an integration test is very, very hard - I like integration tests, but less tests testing huge swathes of code (and I say testing loosely) would not give me the same confidence of detailed unit tests though I do think they are important to have (just not as a replacement). | |
| Jan 13, 2014 at 16:39 | comment | added | gbjbaanb | @Michael then you just haven't put enough effort into the testing, I did say it is more difficult to do good integration testing as the tests have to be much more detailed. You can supply bad data in an integration test just as easily as you can in a unit test. Integration testing != happy path. Its about exercising as much code as you can, that's why there are code coverage tools that show you how much of your code has been exercised. | |
| Jan 13, 2014 at 16:37 | comment | added | gbjbaanb | @Ptolemy I think the rarity of 2 buggy components cancelling each other out is far,far lower than 2 working components interfering with each other. | |
| Jan 13, 2014 at 16:34 | comment | added | Michael | And from experience, it's rarely bugs in the happy path that are the problem! | |
| Jan 13, 2014 at 16:34 | comment | added | Michael | Code coverage != tested - aside from bugs cancelling each other out, what about scenarios you've never thought about? Integration testing is fine for happy path testing but I rarely see adequate integration testing when things aren't going well. | |
| Jan 13, 2014 at 15:15 | comment | added | Michael Shaw | Not quite true... With integration tests its possible to have two components that are both buggy, but their bugs cancel out in the integration test. It doesn't matter much until the end user uses it in a way in which only one of these components is used... | |
| Jan 13, 2014 at 14:48 | history | edited | gbjbaanb | CC BY-SA 3.0 | reformatted, minor wording change |
| Jan 13, 2014 at 13:31 | history | answered | gbjbaanb | CC BY-SA 3.0 |