Printable View
I came across a presentation on Unit testing which contained the following (there were others too) as characteristics of Unit Testing :
- Negative or Destructive Testing
- Memory Leaks and Exception Handling
Negative or Destructive Testing is done across Integration / Component tests through.
So are memory leaks etc.
Why do you think they are explicitly mentioned here ?
Also, is code coverage (as part of unit testing) an effective means of detecting faults? How much coverage is enough?
Destructive testing is key to unit testing a single class. For instance, lets say we have a Calculator class, and one of its methods is divide(int dividend, int divisor). One of your unit tests should cover passing 0 as the divisor, otherwise you can't guarantee your program won't crash by using it incorrectly. This is a destructive test (testing for failure).
As far as code coverage goes, I've never seen a solid percentage. My rule of thumb is to have at least one test per branch of execution. If you use TDD, you'll never write code for something you don't already have a test for, so your code coverage should be close to 100%.
I believe that even without TDD we (developers) should strive for the 90% mark for sure (unit tests).
Integration tests should in my opinion also cover at least 70% of code (assuming that 30% of code are rare cases)
Laurent