JUnit Anti-mode

The advent of JUnit brought the gospel to the developer. Unfortunately, many people still think it's enough to learn the JUnit API, write a few tests, and finally get a good test application. This is worse than not doing any testing, because it can lead to misunderstandings about the health of the code. Learning JUnit is the easiest part of the test. Writing good tests is a difficult part. This article describes some of the common JUnit anti patterns and explains how to resolve them.

Two months ago, my wife and I decided to put wood panelling in the kitchen. This is my first time to decorate the house, with a spirit of blind optimism, the use of hammers and nails to dry up the decoration. But it was almost a disaster, because I didn't use the hammer well. Finally, my wife had to rearrange the plates and cracks that were so uneven.

In decorating the bedroom, I think has learned some lessons, this time borrowed father-in-law's gas nail gun. Only used to decorate the kitchen one-tenth of the time, the bedroom was decorated, but the gas-nail gun did not make up for my other mistakes-for example, forgetting to keep the level of the top of the plank, cutting the board in the wrong place, forgetting to check the plank, nailing the cracked planks, and so on. There were many other problems, which fortunately had been noticed by attentive wives. Through this matter, I realized: the gas nail gun is inferior to a carpenter.

JUnit: gas-nail gun test tools

I think JUnit is like Dad's gas-nailed gun. Testing was not impossible before JUnit appeared, but it was very difficult. In fact, it's so difficult that no one is usually willing to test it. Even testing is only part of what looks particularly complex or fragile, so that people have reason to carry out extra tests.

JUnit is a special tool for solving this problem. The dirty secret here is that many programmers are actually happy to write tests. This causes the programmer to write the test, and the customer expects the test case. Although there are still some who insist, most customers are now inclined to use our new dominant JUnit in the test field. (For more information on loving testing, see resources).

The problem is that JUnit is not a panacea, it is a veritable tool. Like other good tools (JUnit is one of the best tools), JUnit does one thing and completes it brilliantly, providing a framework for executing tests. The specific performance in:

JUnit provides a template for writing tests that can be installed, executed, and uninstalled.

It allows you to organize your tests in a hierarchical structure.

It allows you to perform tests automatically and easily.

It reduces the amount of test reporting from the execution process, allowing the use of different test procedures in the same test suite.

Although JUnit is powerful and simple to use, it also has a number of drawbacks that require other tools to fill these gaps. The following are not possible for JUnit:

Automatically generate tests for the units being tested.

Provide coverage conditions.

Tips when writing bad tests.

Stated point of view

Robert Binder has written a good book named testing object-oriented Systems:models, Patterns, and Tools. Binder is a rare genius--a test sage. As a reference to the test, the value of the book is beyond measure. Binder at the beginning of the book again about Scott Meyers's test. The problem is to write unit tests for Triangle objects.

Java™ Technology implements a constructor that takes three side lengths. Each side has a getters and setters. There are three ways to implement this technique: Isisosceles (), Isscalene (), and isequilateral (), each of which can return true or false, depending on the configuration of the triangle. Triangle is also a subclass of the Polygon type, which is derived from the Figure class. Figure is an abstract class that represents objects that can be depicted by raster displays. The challenge now is how to write tests of this type.

Binder lists 33 tests from Meyers's original program solution and provides 32 tests that are closely related to object-oriented problem properties. So now there are 65 tests. Unless it is an important software that affects life security, you may never test the code in such detail, nor do you know that it was so tested. The reason is not that you are physically deficient or lazy. Rather, you are not trained in testing, and because you are consuming your dedicated development time on programming skills rather than on testing capabilities. What should I do? JUnit makes testing simple and easy to do.