Pursue code Quality

In essence, a test framework like JUnit and TestNG facilitates the creation of repeatable tests. Because these frameworks take advantage of the reliability of simple Boolean logic (in the form of an Assert method), this makes it possible to run tests without human intervention. In fact, automation is one of the main advantages of the test framework-I am able to write a fairly complex test for asserting specific behavior, and once these behaviors change, the framework reports a mistake that everyone can understand.

It is obvious that the use of a mature test framework brings the benefits of a framework repeatability. But the repeatability of logic depends on you. For example, consider creating a situation where repeatable tests are used to validate Web applications, and some JUnit extension frameworks, such as Jwebunit and HttpUnit, are useful in helping automate Web tests. However, it is a developer's task to make the test plumbing repeatable, which is difficult to do when deploying WEB application resources.

The actual jwebunit test is fairly simple to construct, as shown in Listing 1:

Listing 1. A simple jwebunit test.

package　test.come.acme.widget.Web;

import　net.sourceforge.jwebunit.WebTester;
import　junit.framework.TestCase;

public　class　WidgetCreationTest　extends　TestCase　{
　 private　WebTester　tester;

　 protected　void　setUp()　throws　Exception　{
　 this.tester　=　new　WebTester();
　 this.tester.getTestContext().
　　 setBaseUrl("http://localhost:8080/widget/");
　 }

　 public　void　testWidgetCreation()　{
　 this.tester.beginAt("/CreateWidget.html");
　 this.tester.setFormElement("widget-id",　"893-44");
　 this.tester.setFormElement("part-num",　"rt45-3");

　 this.tester.submit();
　 this.tester.assertTextPresent("893-44");
　 this.tester.assertTextPresent("successfully　created.");
　 }
}

This test communicates with a WEB application and attempts to create a widget that is based on that interaction. The test then verifies that the part was successfully created. Readers who read the previous section of this series may notice a subtle repeatability of the test. Did you notice? What if this test case runs two times in a row?

The verification aspect of this widget instance (i.e., Widget-id) makes it safe to assume that the database constraints in this application are likely to prevent the creation of an additional widget that already exists. This test case is likely to fail because of the lack of a process to remove the target widget from this test case before running another test, and if you run it two times in a row.

Fortunately, as discussed in the previous article, there is a mechanism to help with the repeatability of database-dependency (database-dependent) test cases-that is, DbUnit.