One bug at a time
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 .
- Project JXTA Town Hall Meeting, Tuesday, September 16th
- Sun's Papadopoulos, Joy's Replacement, Looks Ahead
- Morena 6.0 Released
- Limewire 3.5.7 Offers iTunes Integration
- Jext 3.2 Pre 3 - 1 Released
This blog is delivered weekdays as the Java Today RSS feed. Once this page is no longer featured as the front page of
href="http://today.java.net"> Java Today it will be archived at
http://today.java.net/today/archive/index_09122003.html. You can
access other past issues by changing the address appropriately.