News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

2/10/2010 to 2/12/2010
San Francisco
BZ Media

2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

2/19/2010 to 2/20/2010
Los Angeles
SCALE

2/21/2010 to 2/24/2010
Las Vegas
IBM


 
Most Read Latest News Blog Resources

TestNG Is A-OK




July 15, 2006 — 
Test-driven development (TDD)—where you write the tests before you write the code, and run the tests every 10 minutes or so as you’re coding—is something everyone should be doing. Not only does TDD make the code go together faster with fewer bugs, but it also takes a lot of tension out of day-to-day programming tasks. The worst-case scenario when you introduce a bug is throwing away the last 10 minutes of work.

To practice TDD, however, you need an easy-to-use automated test environment, ideally one that can be customized for the work at hand. For example, you may want to run only a small set of localized tests every 10 minutes, with a more thorough, but slower, test pass every hour or so.

JUnit has been the standard for this sort of testing, but JUnit has its problems. It’s difficult to set up JUnit to run several disconnected tests in a single run, for example. There’s also no easy way to chain tests (where a test depends on the success or failure of a previous test—JUnit test methods each run in their own objects, even if they’re declared in the same class, so they can’t easily interact with one another). You also can’t get fine control over which tests run, so it’s difficult to customize a test suite to the code you’re working on right now.

I also have mixed feelings about JUnit’s insisting on putting test methods in special test classes. On one hand, the separate-class approach lets you exclude the tests from the shipped code. Just omit the .class files. On the other hand, I get nervous when the tests and the code aren’t in the same class definition. It’s too easy to not add a test when you add new code.

There is an alternative to JUnit that fixes these problems: TestNG (www.testng.org), a test framework written by C?dric Beust and ported to Java 1.4 by Alexandru Popescu. (There's a testing tutorial at membres.lycos.fr/testng.)

TestNG leverages Java 5 annotations to tag normal methods in your classes as tests. (A JDK 1.4 version does the same with javadoc-style comments.) The test methods can be in their own classes, but don’t have to be. A separate XML file specifies which classes (or packages) to test, and which tests to run within these units. (A “test” is different from the method that implements some or all of the test. Methods are added to named tests by specifying the test name in the annotation that tags the method definition.) You have very fine control over the composition of a test run, and it’s easy to configure a run for a specific situation.

Like JUnit, TestNG integrates nicely into Eclipse, IDEA, Maven and Ant. You can also easily modify the actual test-runner program to accommodate special test scenarios or even run TestNG from a separate program.

Though I think TestNG is better than JUnit, it’s not without flaws. I hate the syntax of the XML configuration file. Everybody seems to have forgotten how to build special-purpose small programming languages using tools like YACC. Small languages are good. They’re easy to write, easy to learn, and let you express targeted semantic concepts in simple ways. Using them, you can get work done faster.

A myopic focus on XML, however, results in a host of bad XML-based programming languages. You must express simple concepts with ungainly globs of angle brackets, attributes and other syntactic garbage. Imagine having to do all your programming in XML rather than Java. Your programs would be two orders of magnitude larger, impossible to read and impossible to maintain. XML is good for absolutely nothing except data description, and it’s not particularly good at that if you care about things like bandwidth.

The worst example of this XML-as-programming-language stupidity is Ant, which is nothing but a very hard-to-read scripting language. Everything that you can do in Ant, you can do better with any number of shell languages (Bash, Korn, Bean, etc.), any of which could be made platform-independent with a simple port to Java.

Returning to TestNG, most of the complexity in TestNG is in writing the XML configuration file that describes how your tests should run. This file is a perfect example of a place where a focused test-description language would excel. To me, the XML file is a serious wart in an otherwise good program. A lot of what’s expressed in the XML could be expressed directly in the annotations, with no need for a test script at all. Complex testing situations should be expressed in a purposed scripting language, not in XML.

That said, I think that TestNG does offer a few significant advantages over JUnit. It’s certainly worth serious consideration.

Allen Holub is an architect, consultant and instructor in C/C++, Java and OO Design. Reach him at www.holub.com.


Share this link: http://www.sdtimes.com/link/29435
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading