Re: Junit newbie
- From: darrell@xxxxxxxxxxxxxxxxxx (".")
- Date: 21 Nov 2005 19:07:31 GMT
On Fri, 18 Nov 2005, Jason wrote:
> I'm not getting junit at all.
>
> Is the general strategy to write trivial tests, boundary tests, and perhaps
> a "range of data" test? It seems like I can easily spend a 3:1 ratio of
> time in junit versus my actual class. And testing would still be kicking
> around in the dark.
>
> Let's say I'm writing a compression class similar to a stream (because I am)
> which only reads and writes byte arrays. What would the minimum testing
> include? How about:
>
> de/compress a null
> iteratively test de/compressing a single byte array with the values ranging
> from 0 to 0xFF
> test de/compressing some very large byte array (from a file 2GB file
> perhaps)
> test de/compressing some random data
>
> As for the last one, I'm not even sure that's useful as the test conditions
> that caused the failure would be squirrely. The condition would almost
> certainly rely on the previous compression attempt and that debugging info
> will be lost before the test fails.
>
> Can someone take pity an give me the big picture on this stuff?
I've seen this a lot in classes I taught. A portion of the assignment goes
towards testing the application. Some students will write a 50 line
application and hand in, literally, 30 pages of test output.
You can narrow the testing down a little by thinking about how things can
be grouped. If the start of a method begins with an:
if (case 1 is true) {
// something
} else if (case 2 is true) {
// something else
} else // case 3 is true) {
// whatever is left
}
I'm going to need at least 3 tests in jUnit.
If you have been programming for a while you noticed that at first you'd
right out 10 different if/elseif/else statement. As you refine the program
you realize that the solution for case 1, 3 and 7 is the same so you
combine them. This forms a compound boolean statement. There might be
multiple ways into the statement. Some will say you need 3 test cases for
the 1 boolean statement. The logic is that if someone messes up part of
the statement you might catch it. Others say that you only need 1 test
case because all 3 will exercise the same body; i.e. they are equivalent
test cases so you only need to pick one. Having 3 test cases for the 1
statement is safer. Is your boss willing to invest the time to code and
maintain them all?
As to what if test2 requires test1 to pass? I like to set up my tests is
the setup() function provides everything necessary for the test to
proceed. Therefore, the setup() for test2 is to ensure that the output for
test1 exists.
Another option is to map the dependencies and have test2 check if test1
failed. If test1 fails, don't even bother running test2. Or have an assert
at the beginning of test2 that checks for the success of test1 and outputs
good information in the log, i.e. "test2: failed. Relied on test1, which
failed."
I like to do the latter. That way if 3047 tests rely directly or
indirectly on test1 and test1 fails. The other 3047 tests are unknown.
Unknown is not a failure but it is a potential failure; could impact
schedule.
Finally, the de/compressing random data is a potentially good test. You
want to test that your code does what it is supposed to do but you also
want to test that your code does not do what it is not supposed to do. For
example, if you give it bad data it should die gracefully. It should not
format the hard drive, corrupt data or reboot your computer. It should
recover nicely.
--
Send e-mail to: darrell dot grainger at utoronto dot ca
.
- References:
- Junit newbie
- From: Jason
- Junit newbie
- Prev by Date: Re: compile error: System is out of resources..
- Next by Date: Re: java for beginners
- Previous by thread: Re: Junit newbie
- Next by thread: Re: Junit newbie
- Index(es):
Relevant Pages
|
