|
-
June 10th, 2010, 06:47 AM
#1
Understanding of Unit Testing
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?
Last edited by humble_learner; June 10th, 2010 at 06:56 AM.
-
July 7th, 2010, 12:03 AM
#2
Re: Understanding of Unit Testing
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%.
-
August 28th, 2011, 04:20 PM
#3
Re: Understanding of Unit Testing
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
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|