Skip to main content

One bug at a time

Posted by daniel on September 12, 2003 at 5:12 AM PDT

When chasing bugs in legacy code, Luke Francl finds that he can't run his entire suite of tests all the time. Francl has created an Ant task and supplemented JUnit so that he can run specific test methods in a particular class in his Test suite.

In his feature article Running Individual Test Cases from Ant, Luke Francl shows you how to run tests from a single class or even individual test methods using JUnit and Ant. Francl first shows you a runtest Ant task that take the name of a test class as a parameter. You could already accomplish this by putting a main() in the class to be tested and using the optional junit task. The method presented in the article feels more flexible. You can decide to run a particular test class at the last minute simply by passing it's name in from the command line if you like.

Next Luke augments the runtest task to run tests from one or more methods. This also requires adding to the JUnit framework. In turn, this means that "When writing a TestCase , [you] use TestUtils.hasTestCases to check for the tests property, and use TestUtils.getSuite with the Class object for your TestCase subclass to return the dynamically constructed TestSuite. Otherwise, construct and return the TestSuite as usual."

Luke and I emailed back and forth quite a bit during the editing process. My question was "why would you want to run a particular method from a single Test Class". He answered that sometimes you are chasing a single bug and want to just run a couple of tests. I'm ok with running tests from a particular class or package but worried about the more granular approach. How do you make sure that as you cycle and fix the bug exposed by one particular test that you aren't introducing bugs that would have been caught by other tests that you aren't currently running.

Luke responded in two ways to this in the text. First he answered:

[N]ot everyone has the luxury of using the test-first approach. The techniques discussed in this article were developed to deal with writing test cases for an existing, completely untested system.

Second he mentioned that he will

write a test method (or three) to exercise the bug, and then run those test cases repeatedly as I work on the bug. In an untested system, tests rarely are completely self-verifying, so I'll need to look at the log output. Being able to look at the output from only one test case is helpful for debugging. Another reason for wanting to run only a few tests is that tests often take a long time to run.

In today's featured Weblogs Erb Cooper discusses The Terror That Is Autoboxing. He asks whether the Department of Javaland Security should step in and squash the possibility that thousands of objects will be created under the covers without him even realizing it?

In the Also today section we link to two items on communicating over the net. In Frank Sommers' piece Why Use SOAP? he considers when SOAP is the right tool for a job. Often, he suggests, when you are reaching for SOAP a simpler homemade protocol for sending XML over the wire may be more appropriate. The second piece is the latest Core Java Tech Tip. In Working with SocketChannels I walk you through a simple client/server application using SocketChannels. If you control both ends of the wire, a simpler approach may be what's called for.

From the Java Today News Page, news editor Steve Mallett, has gathered the following News Headlines .

Registered users can submit news items using our submission form. All submissions go through an editorial review before being posted to the site. You can also subscribe to the News RSS feed.

This blog is delivered weekdays as the Java Today RSS feed. Once this page is no longer featured as the front page of href=""> Java Today it will be archived at href=""> You can
access other past issues by changing the address appropriately.