How much testing is enough?
10/7/09, 14:26
(No Ratings Yet)
Loading ...
(No Ratings Yet) Loading ...I recently spent about 70% of the time coding a feature writing integration tests. At one point, I was thinking “Damn, all this hard word testing it, I know I don’t have bugs here, why do I work so hard on this? Let’s just skim on the tests and finish it already…”
Five minutes later a test fails. Detailed inspection shows it’s an important, unknown bug in a 3rd party library we’re using.
So … where do you draw your line on what to test on what to take on faith? Do you test everything, or the code where you expect most of the bugs?
Boaz:
Also, how do you know your code is well tested? Do you just think/write all the tests you want to write that test every feature of your code? Do you rely on code coverage?
11/7/09, 20:03ripper234:
We don’t usually use code coverage tools. I personally try to write tests for the meaningful/complex features, and the tests that are easy to write. You probably don’t want to write tests that are both difficult to write and maintain and are sure to pass – but it’s not always easy to spot them in advance.
11/7/09, 22:20Yaron Naveh:
The easy tests I actually do the “test-first” way – write them before the code.
I sometimes do it also for more “complex” tests – but we have to be careful here: In my current project many features are agile in their nature and changes in api (or even functionality) are not rare. Maintaining tests for “agile” features can be very frustrating, especially when I need to explain my peers why tweaking a simple method functionality takes more than a second…
25/7/09, 23:58yonatan:
Yaron: I agree about simple tests (preferably a test method per single behavior of a single method in the class being tested) – although it can be frustrating having to refactor your unit tests along with your code, usually I think you need to write tests / make the tests pass after a refactoring anyway, so the price isn’t so big.
26/7/09, 20:05imho integration tests don’t help you refactor as well, they are more suitable for when you already have a feature working and wanna make sure it’s according to spec and that it stays ok. you can also make them more configurable so your clients can add cases without coding and recompiling (see fitness etc)