I’m afraid this is the reality we all too often have to deal with. Certainly you’d like to perfectly understand every part of your system, but what do you do when you don’t? Throw up your hands in the air and refuse to fix anything because you might break something else?

Pascal’s story is particularly interesting because he did not start out with a solid test suite. He had to develop the test suite as he went.

I work exclusively with offshore developers in India. The India-based organization we work with sees frequent turnover of developers. Developers also are responsible for understanding the internal functions of numerous applications. Often when a new developer is brought on board we are in the middle of several small/simple, yet critical, tweaks to a system. Often we do not have the time to wait for the developer to get 100% complete understanding of some of the complex applications before making simple changes. TDD with very thorough suites of test cases combined with code profiling applications (Eclipse TPTP, etc.) and code coverage applications (Cobertura) allow developers to make changes to our code, run full test suites, send JUnit, code profiling, and code coverage reports to project managers here in the U.S.

Through this process we have been able to keep code quality high, bugs low, and provide flexibility on projects that might otherwise have had to been delayed.

Given this is not necessarily an average case, but does happen at least once or twice a year.

testFailingOp() {
  try {
    doSomethingBad();
    fail("No exception thrown");
  }
  catch (Exception ex) {
    // Cool. the code worked as expected.
  }

However most static code analysis tools will flag that as an empty catch block. I sometimes test the exception message just to avoid that.

Here’s another one: JUnit test method names can be extremely long. For instance, one of XOM’s is testConvertSingleElementDocumentFromXOMToDOM. Some static code analysis tools will flag that as an exceptionally long method name, and normally they’d be right; but not here.

They’re a lot of other areas where the usual rules are actively misleading when applied to JUnit tests.

Finally keep in mind that test code, although public, is not meant to be reusable or to be invoked by anything other than a test runner. That also suggests it doesn’t follow the same rules as most code does and can get away with simpler rules because it’s simpler code. The unit nature of unit tests means the tests can be considered in isolation, and thus it’s not nearly as important to sand down all the rough edges as it is in code where each method will be just one cog in a well-oiled program.

Yup. I run code checkers on all kinds of open source code all the time. By far the lousiest code out there is the code found in junit tests.

In fact, I think a test is better precisely if it doesn’t have any special dependence on how the model code operates. This allows more flexible programs because you can refactor and experiment and try different algorithms and approaches without changing the tests. This is the whole point of data encapsulation. The class is a black box which is accessed solely through its public interface. The internal details are deliberately opaque, and thus can be changed as necessary to improve performance or other desirable characteristics without breaking client code.