Re: Junit newbie
- From: "Oliver Wong" <owong@xxxxxxxxxxxxxx>
- Date: Mon, 21 Nov 2005 20:10:28 GMT
"Jason" <jason@xxxxxxxxxxxxxxxx> wrote in message
news:Hj9ff.1922$2k6.58@xxxxxxxxxxxxxxxxxxxxxxx
> I'm not getting junit at all.
>
> Is the general strategy to write trivial tests, boundary tests, and
> perhaps a "range of data" test?
One strategy is to write tests until you don't feel like you're writing
useful tests anymore.
Another strategy is to imagine yourself as being a "lead programmer" to
has to delegate work to "junior programmers". You assume that the junior
programmer has a vague idea of what the method (s)he has to code is supposed
to do, but doesn't know the details (e.g. what should happen at the
boundaries, like you mentioned above). Write enough tests so that the junior
programmer can be relatively confident that his/her code works, without
coming back to you to ask for clarifications.
Also, while coding, if you notice a bug, it's usually a good idea to
write a test which will detect that specific bug so that it doesn't slip by
again.
It might also be worth considering both "black box testing" and "glass
box testing". In the former (black box), you don't assume anything about the
implementation. You write tests that make sure the method does what it's
supposed to do, and that's it. In "glass box testing", you know what the
algorithm is that implementing the feature you're testing, so you'll write
tests which will ensure every line of code gets executed at least once (e.g.
make sure that both the "true" and "false" paths of every if statement are
taken).
Usually you'll want to have a good mix of black box and glass box
testing.
> It seems like I can easily spend a 3:1 ratio of time in junit versus my
> actual class.
It's not unusual in test-driven development for one to spend more time
writing tests than writing code.
> 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.
Some people feel tests should be fast or else you won't want to actually
run the test. If you agree with this philosophy (I don't), then you probably
want to avoid the 2GB test file as that'll probably be a long test.
Some people have configured their IDEs to automatically run unit tests
immediately after a compilation, so that the failed tests actually show up
in the error logs (e.g. as compilation errors or warnings).
- Oliver
.
- Follow-Ups:
- Re: Junit newbie
- From: Monique Y. Mudama
- Re: Junit newbie
- References:
- Junit newbie
- From: Jason
- Junit newbie
- Prev by Date: Re: For those Deprived Of Homework
- Next by Date: Re: For those Deprived Of Homework
- Previous by thread: Re: Junit newbie
- Next by thread: Re: Junit newbie
- Index(es):
Relevant Pages
|
