The Disco Blog

As I’ve written about before, TestNG-Abbot is a newly minted testing framework that breathes new life into testing GUI components. If you are currently writing or maintaining Swing or AWT applications, then check out developerWorks‘ “Automate GUI testing with TestNG-Abbot” and you see how surprisingly easy it is to isolate GUI components and then verify them using TestNG-Abbot’s handy fixture objects.

As always, don’t forget to Swing (no pun intended) over to the “Improve Your Java Code Quality” forum and let it all hang out, man!

I’ve written a few articles that cover one of my favorite frameworks; however, that doesn’t mean I don’t dig JUnit 4. In fact, I’ve just published a tutorial on all things JUnit 4. In this tutorial, I show you how to leverage the new and copasetic features enabled by annotations, including parametric tests, exception tests, and timed tests. I also introduce JUnit 4’s flexible fixtures and I show you how to use annotations, rather than suites, to logically group tripped out tests before running them.

Check out Disco dancing, I mean “Jump into JUnit 4” and, if it’s your bag, let it all hang out at the “Improve Your Java Code Quality” forum!

While defensive programming techniques (like checking if a parameter is null or not) effectively guarantees the condition of a method’s input, these conditionals become repetitive if they’re used across a wide expanse of code. In this month’s In pursuit of code quality series on IBM developerWorks, I introduce an easier way to add reusable validation constraints to your code using the power of AOP, design by contract, and a handy library called OVal. Check out “Defensive programming with AOP” and don’t forget to boogie over to the “Improve Your Java Code Quality” forum and let it all hang out, man!

From time to time, you may need to verify the structure or content of XML documents– in this month’s In pursuit of code quality series, “Discover XMLUnit” shows you why you don’t want to use String comparisons to verify the structure and content of XML documents. Then it introduces XMLUnit, a hip XML validation tool and shows you how to use it to validate XML documents.

Also too, don’t forget to get your groove on at the “Improve Your Java Code Quality” forum!

Performance testing is usually left for last in hip application development cycles– not because it’s unimportant, but because it’s hard to do effectively with so many unknown variables. IBM developerWork’s “In pursuit of code quality: Performance testing with JUnitPerf” makes the case for performance testing as part of the development cycle and shows you two easy ways to do it with Mike Clark’s JUnitPerf framework. Check it out, man!

Because it’s your bag baby, don’t forget to let it all hang out at the “Improve Your Java Code Quality” forum too!

Implementing test categories with TestNG couldn’t be any more copasetic, man! With TestNG’s group annotation, logically dividing tests by category (like unit, component, or system) is as easy as applying a specific tag to a desired test– then bingo, baby!

I’d explain how to do it all here, but the tripping crew at Dev2Dev has just published “Test Categorization Techniques with TestNG” by yours truly! Outta sight!

Writing logically hip repeatable tests is especially tricky when testing copasetic Web applications because of the complexity associated with setting up a web environment. It’s easy to write the test– what’s challenging is reducing assumptions regarding how the test will run.

IBM developerWork’s “In pursuit of code quality: Repeatable system tests” introduces Cargo, an open source framework that automates container management in a generic fashion, so you can write logically repeatable system tests every time.

Also too, don’t forget to let it all hang out at the “Improve Your Java Code Quality” forum!

With its hip annotations and free-wheeling syntax, JUnit 4 has embraced some of the best features of TestNG, but does that mean it’s rendered TestNG obsolete like shiny clinging Lycra stretch disco pants and copasetic disco moves? Obviously, the answer is no because:

• Lycra stretch disco pants are still hip as ever
• TestNG has plenty of features not available in JUnit 4
• Disco record sales are up 600% in the year 1974

IBM devWork’s JUnit 4 vs. TestNG considers what’s unique about each framework and discusses three high-level features you’ll still find only in TestNG. Dig it?

Believe it or not, there are numerous Struts applications alive today. They may not be the hippest things going, but they have business value so they’re in no hurry to go anywhere, at least until the cost to maintain them supersedes the cost to rewrite them. Until that point, it makes copasetic sense then to roll up your sleeves and test those applications so as to reduce the risk of introducing defects as modifications are made, right?

“Testing Struts legacy apps” is the latest article in IBM developerWork’s series “In pursuit of code quality”, which focuses on using the StrutsTestCase framework, in concert with DbUnit, to facilitate testing those omniscient Struts Action classes. As always, feel free to let it all hang out at the “Improve Your Java Code Quality” forum!

For additional resources on testing Struts applications see:

• StrutsTestCase simplifies the development process (DeveloperWorks, 01/05)
• Unit Test Your Struts Application (OnJava, 09/04)
• StrutsTestCase: The Tool for Struts Unit testing (Java Boutique)
• Component test repeatability (The Disco Blog, 02/06)

For additional resources on using DbUnit see:

• Effective Unit Testing with DbUnit (OnJava, 01/04)
• Practically Groovy: Of MOPs and mini-languages This article shows how to use DbUnit with Groovy (DeveloperWorks, 08/05)
• Isolated unit testing of persistence with Derby (DeveloperWorks, 11/05)
• Data diff’n with DbUnit (The Disco Blog, 07/06)

It seems every time I give my Refactoring with code metrics presentation, someone has an acid flashback and tells about the 10,000 line method they ran across in the hunt for a crippling defect. When I was speaking at the PhillyJUG in 2005, I distinctly remember a hip gentleman volunteering he once worked on an application that had a smokin’ 22,000 line method.

Long-winded code may be a badge of courage and often makes for copasetic jokes, but ultimately this kind of code is a bear to maintain and is impractical to test effectively, man. The sixth article in IBM developerWork’s series “In pursuit of code quality” demonstrates three neat-o ways to measure code complexity, based on method length, class length, and intra-class coupling with both PMD and JavaNCSS.

Check out “Tame the chatterbox” and, if it’s your bag, let it all hang out at the “Improve Your Java Code Quality” forum!