Need help designing some JUnit tests

[Tom Anderson]

One good thing about TDD, which has been mentioned elsewhere in this thread
(and in other threads), is that you can slide tests in as part of the
implementation, with no non-technical managers any the wiser.

A crafty move in this situation is to selectively write tests for the
tricky bits. They'll help you get them right, and keep them right, with
less effort, and that serves as a useful evangelical point. Once people
see the utility of tests for some bits of code, they're on the road to
seeing the utility of them for the whole codebase.

tom

 

[Arne Vajhøj]

news:jlvJn.4710$z%6.465@edtnps83:

[ SNIP ]

I see that you've given some good concrete suggestions for tools to
use in upcoming paragraphs. Are any of these static code analysis
tools? If not, can you suggest some good ones? I'd love to have some
feedback on my code via code reviews too but that's a little difficult
to do. It's not realistic to full (non-trivial) classes in the
newsgroup so I just pick and choose especially concerning problems and
post snippets reflecting them. I'm sure that you folks are all too
busy to do detailed walkthroughs of dozens of classes with hundreds of
lines of codes in many of them ;-) I must see if there is a local Java
user group in this area and see if I can develop a few buddies for
doing code walkthroughs....

[ SNIP ]

FindBugs, if you're not using it already, is a good static code
analyzer. In my experience, just one decent tool like that, plus the
requisite excellent books like Bloch's "Effective Java" and willingness
to spend time reading those books to understand what the analyzer tells
you, is all you really need.

It's also useful to complement FindBugs with Checkstyle, which latter is
a good part of your toolkit for other purposes as well.

Have you tried PMD?

If yes how does that stack up against those two?

Arne

 

[Arne Vajhøj]

Probably 'test-driven development', aka TDD.

And it's no more of a buzzword than 'wearing a seat-belt'. It's just a
bloody good idea!

I have no doubt that:

success(TDD) > avg(success(all methodologies))

but I am not quite as convinced that:

success(TDD) > avg(success(methodologies with strong focus on unit tests))

Unit tests is definitely good.

But the middle D and its implications for the design process is
more debatable I think.

Arne

 

[Arne Vajhøj]

This principle is also very important for bug fixing. Any bug represents
a defect in the test suite. Fix the test suite first, and verify that
the new tests fail, before any attempt to fix the underlying bug.

Furthermore there is the phenomenon that if a bug was "natural" to
make then there is an increased chance that some maintenance
developer will reintroduce the bug later.

We want to catch that.

Reintroducing bugs does not make bosses and customers happy.

Arne

 

[Tom Anderson]

I have no doubt that:

success(TDD) > avg(success(all methodologies))

but I am not quite as convinced that:

success(TDD) > avg(success(methodologies with strong focus on unit tests))

You may be right. I tend to think:

TDD == methodologies with strong focus on unit tests

Although that's probably just my biases. What are other methodologies that
have a strong focus on unit tests? Are they test-first or test-after? What
is a test-first method that's not TDD?

tom

 

[Arved Sandstrom]

news:jlvJn.4710$z%6.465@edtnps83:

[ SNIP ]

1. Code reviews/inspections and static code analysis with tools _are_
a form of testing. Keep them in mind.

I see that you've given some good concrete suggestions for tools to
use in upcoming paragraphs. Are any of these static code analysis
tools? If not, can you suggest some good ones? I'd love to have some
feedback on my code via code reviews too but that's a little difficult
to do. It's not realistic to full (non-trivial) classes in the
newsgroup so I just pick and choose especially concerning problems and
post snippets reflecting them. I'm sure that you folks are all too
busy to do detailed walkthroughs of dozens of classes with hundreds of
lines of codes in many of them ;-) I must see if there is a local Java
user group in this area and see if I can develop a few buddies for
doing code walkthroughs....

[ SNIP ]

FindBugs, if you're not using it already, is a good static code
analyzer. In my experience, just one decent tool like that, plus the
requisite excellent books like Bloch's "Effective Java" and willingness
to spend time reading those books to understand what the analyzer tells
you, is all you really need.

It's also useful to complement FindBugs with Checkstyle, which latter is
a good part of your toolkit for other purposes as well.

Have you tried PMD?

If yes how does that stack up against those two?

Arne

I'm not able to give a strong opinion on PMD, Arne. I tried it to the
extent of downloading it, running it on the command line with some
options (selecting rulesets), and briefly inspecting the reports. The
context was that I'd already routinely been using FindBugs on the same
codebase.

My impression was that it was a competent static analyzer, but seeing as
how I already use the other two, that the extra effort of going through
yet another set of reports outweighed the gains of PMD catching a few
things that FindBugs might not, for example. Lots of overlap, IOW.

AHS

 

[Arne Vajhøj]

You may be right. I tend to think:

TDD == methodologies with strong focus on unit tests

Although that's probably just my biases. What are other methodologies
that have a strong focus on unit tests? Are they test-first or
test-after? What is a test-first method that's not TDD?

To me it is a 3 level thing:

level 1 = unit tests everything
level 2 = write the unit tests before the code
level 3 = let the unit tests drive the design

I like up to level 1.5 (unit test everything, either write the
unit tests first *or* get another developer to write the
unit tests).

Arne

 

[Tom Anderson]

Ah, i think of test-driven design as meaning the same thing as test-driven
development - they're just different names for the same thing.

Test-driven design as a term is a misnomer anyway. You are doing design
bit-by-bit as you go along, but it's not driven by the tests. It can't be
- if we understand 'design' to mean something like 'architecture' or
'design at a level higher than source code', then it's the design which
drives the tests, because the design is what gives you "i need a class
which embodies such-and-such an idea, and exposes operations this-and-that
to its clients". Having design *driven by* tests is an impossibility.

I suppose test-driven development could be done with a big up-front
design. There's nothing contradictory there. Indeed, even with incremental
design, at every stage you have a picture of what the whole system will
look like when it's finished, even if you're only working on one little
bit of it right now. The only difference between that and up-front design
is that with up-front design, you think about it in more detail before you
start, and you give yourself less flexibility to change it once you do.
That's why i don't see a real distinction between them: even with a big
upfront design, not giving yourself flexibility is a mistake, so with that
out of the way, the only difference is how much thinking you do before you
start. That's clearly a continuum, so there can be no hard and fast
distinction between the two kinds of TDD.

I think it depends on the nature of the project. The last non-trivial
piece of code I wrote was a simulation for my Ph.D. research. That
program existed to be changed. The best runs were those that got me
thinking about new questions, causing further changes to the program.
For that, I was at about level 2.9 - a little thinking about design
before I had a failing test, but not much.

I don't think that would work so well for a project with a few hundred
programmers.

I'm not sure there are any methodologies at all that work well for a
project with a few hundred programmers, but that's another story.

My ideal, which I have never achieved, would be to have two sets of unit
tests, one set written by another developer and one set written by the
same person as the code under test.

That would be interesting. A while ago, we were working with some
contractors who were not great programmers, and who were especially
hopeless at writing tests (they'd write them, because they knew we wanted
them, but they would often not really test anything). I wondered about
managing the interaction between our teams by having us write the tests,
and having them write the code to make the tests pass. That would have
forced them to write better code, and given us a lot more confidence in
what they were doing.

tom