The advent of JUnit has been a boon to developers. Unfortunately, many think it’s enough to learn the JUnit API and write a few tests in order to have a well-tested application. This idea is worse than not testing at all because it leads to a false sense of code health. Learning JUnit is the easiest part of testing. Writing good tests is the hard part. This article presents some common JUnit antipatterns and shows how to resolve them.
I think they got it wrong its GGGGUNIT
HAHAHAHAHA
Simple but clever examples of test antipatterns.
Good article.
The best way to avoid this antipatterns is to use a code coverage tool.
Anyway keep in mind that unit test doesn’t replace QA Testing. JUnit it’s a framework to do Test Driven Design (“design” not exahustive system testing).
All this unit testing stuff is way harder than it should be.
And anything beyond unit tests is the domain basically of elite QA teams.
Most code ships and it hasn’t been tested very well.
Even suggesting that patterns/anti-patterns has a value proposition has gotten to the point of absurdity.
In XP (Kent Beck), I thought acceptance testing by the customer was a worthwhile concept. But it really has not been developed nearly as much as unit testing.
It is very easy for developers to write code that passes all the unit tests and fails every acceptance test. And while unit tests are important, they are not measures of value.
And the beat goes on.