The Disco Blog

There’s myriad ways to validate XML these days; in fact, with Groovy, the mechanics of parsing XML with XMLSlurper couldn’t be easier! Nevertheless, from time to time, because it’s my bag, baby, I’ve found that I’ve needed an easy way to validate XML documents without having to actually parse them myself. Thus, XMLUnit has been a handy framework today as it has been for years.

While XMLUnit is a hip JUnit-style framework, you can certainly leverage it outside of JUnit. What’s more, via easyb’s plug-in framework, using XMLUnit just got a lot easier! For instance, leveraging XMLUnit without the new plug-in required a bit of manual manipulation of XMLUnit’s Diff class and then a boolean verification like so:

import org.custommonkey.xmlunit.XMLUnit
import org.custommonkey.xmlunit.Diff

XMLUnit.setIgnoreWhitespace(true)

scenario "the XMLRepresentationBuilder should build XML", {

 given "a table name and collection of name value pairs", {
   lst = [new ColumnNameValue("LN_ID", 10002130),
     new ColumnNameValue("NIBA&quot", "99.99"),
     new ColumnNameValue("EFF_DATE", "2009-04-01")]
   map = ["LN_ID":"id", "NIBBA":"nb","EFF_DATE":"effectiveDate"]
 }

 then "the XML produced should be valid", {
   rep = new DatabaseTableResource()
   rep.columnNameValues = lst
   rep.columnNameMappings = map
   rep.identifiers = ["LN_ID"]
   out = XMLRepresentationBuilder.buildRepresentation(rep)

   control = """<cmnres id='10002130'>
      <nib>99.99</nib><effectiveDate>2009-04-01</effectiveDate>
      </cmnres>"""					 

   diff = new Diff(control, out)
   diff.identical().shouldBe true
 }
}

Note how in this code it’s necessary to:

• Ensure white space doesn’t cause comparison errors via the XMLUnit.setIgnoreWhitespace(true) call
• Use XMLUnit’s Diff class to compare two documents and then call the identical (or similar) method to actually verify the documents

With easyb’s XMLUnit plug-in, things are a lot simpler! All you need to do is insert a using clause and ensure the plug-in is in your classpath. Watch:

 using "xmlunit"

scenario "XML documents are compared easier via xml unit plug-in", {  

  given "some xml document", {
    control = """<account><id>3A-00</id><name>acme</name></account>"""
  }

  then "the plugin should enable easy comparisons", {
    testXML = """<account><id>3A-00</id><name>acme</name></account>"""
    testXML.shouldBeIdenticalTo control
    testXML.shouldBeIdenticalWith control  //same behavior different call
    testXML.shouldBeIdentical control      //ditto
    testXML.identical control              //ditto
  }

  and "the instance of XMLUnit should be available for use", {
    XMLUnit.version.shouldBe "1.3alpha"
    XMLUnit.getIgnoreWhitespace().shouldBe true
  }
}

Notice that there isn’t any need to alter the white space setting (it’s been done for you in the plug-in — yo can undo it easily too — see the and clause?), nor is it necessary to use XMLUnit’s Diff class — it’s all done under the covers. While this story uses the identical call, there is a corresponding similar call (and related pattern — that is, shouldBeSimilarTo and the like).

Also, the initialized instance of XMLUnit is available should you need further configurations, etc — the plug-in inserts the copacetic instance into the binding available to your behaviors as shown in the and phrase above.

As you can see, the XMLUnit plug-in for easyb makes workin with xml (that is, comparing documents) a lot easier. While there’s plenty of ways to skin a cat, so to speak, this is just one of them — I’ve certainly found it handy from time to time — I think you will too!

You can download the current version of the plug-in at easyb’s Google code site along with a few other hip gems like easyb’s DbUnit plug-in.

Ever find yourself needing to validate XML? If so, you might want to consider using XMLUnit. As I’ve written before:

When you get that feeling that you’re working too hard, you can usually assume someone else has figured out an easier way to solve the problem. When it comes to programmatically verifying XML documents, the solution that comes to mind is XMLUnit.

Indeed, baby, XMLUnit is a trippin’ JUnit extension framework that facilitates testing XML documents — you can use it to validate the structure of a document, its contents, and even distinct portions of the document.

Yet, in this Age of Aquarius, JUnit (indeed, xUnit in general) isn’t the only show in town, man. There are myriad choices when it comes to validating code — TDD, BDD, and even implementations of these ideals. One of my favorite BDD frameworks is easyb (warning: I am biased here). While easyb might look and feel quite differently than good old JUnit, there is nothing to stop you from leveraging existing assets, which were originally built targeting JUnit. That is to say, baby, all those libraries that have been around for years helping developers validate code are usable in easyb!

For example — I’ve already established that XMLUnit is quite helpful in validating XML documents — such as those leveraged in a RESTful web service. Thus, the question is: can a hipster use XMLUnit in easyb? Of course! Watch:

import org.custommonkey.xmlunit.XMLUnit
import org.custommonkey.xmlunit.Diff

XMLUnit.setIgnoreWhitespace(true)

scenario "the XMLRepresentationBuilder should build valid XML", {

 given "a table name and collection of name value pairs", {
  resname = "currentComnWidgRes"
  lst = [new ColumnNameValue("WGT_ID", 10002130),
   new ColumnNameValue("NISB", "99.99"),
   new ColumnNameValue("EFF_DT", "2009-04-01")]
 }

 then "the XML produced should be valid", {
  out = XMLRepresentationBuilder.buildRepresentation(resname, lst)
  control = """<currentComnWidgRes id='10002130'>
                 <NISB>99.99</NISB><EFF_DT>2009-04-01</EFF_DT>
              </currentComnWidgRes>"""
  diff = new Diff(control, out)
  diff.identical().shouldBe true
 }
}

As you can see in the code above, this easyb story uses XMLUnit to compare the output (using XMLUnit’s Diff class) of the XMLRepresentationBuilder class, which builds an XML document from a model. The resulting document is compared to a control document (i.e. the control variable).

Those familiar with XMLUnit and JUnit (or everyone’s favorite framework: TestNG) will note the line: diff.identical().shouldBe true, which logically maps to the days of old when you’d have to write something like: assertTrue("blah blah", diff.identical()).

Just because easyb looks and feels a little different than the establishment (i.e. JUnit + Java) doesn’t mean you can’t leverage all those handy dandy frameworks — if they can be used in Java, they can be used in Groovy. Therefore, they can be utilized in easyb too, baby!

Ever since Agitar lamentably shut its doors earlier this summer, there have been quite a few postings stating, predicting, or refuting the demise of unit testing. In fact, I was lucky enough to be quoted in one hip article regarding this subject written by my good friend Andrew Binstock. In his article, dubbed “Is unit testing dooomed?” Andrew does not, in fact, reach the conclusion that the practice of unit testing is doomed– he merely suggests that there might be sufficient evidence to conclude the practice might have not caught on like most of us think has.

He states that while other languages (Python and Ruby are named) appear to have a strong following of unit testing,

there are signs that, in the Java community at least, resistance has built up against the unit testing idea.

Andrew goes on to note that, in many cases “unit testing seems to offer little value” and that “evangelism [such as TDD] has become so overbearing that it makes unit testing as a whole unappealing.” Because it’s his bag, he then goes on to make a compelling case for unit testing naming four benefits, which, for those of us that actually practice unit testing, are hard to refute:

Defects are identified nearly immediately, and because unit testing isolates their cause and effect, they are also resolved more quickly. As a result, you can be more confident in the schedule. You also get better code-level documentation.

The question remains, however; is unit testing doomed? The answer to this question, of course, depends on your point of view, baby– or more precisely, what kind of development you are currently performing. For, as Andrew noted, if you are currently practicing Agile development, where unit testing has taken a strong hold and where “developers write hundreds of small tests for exercising their own code” the answer to the former question is a resounding no!

Unit testing is thriving in that crowd– people often claim (me included) that they can’t live without it! In fact, to the multitude that lives and breathes unit testing, the subject has most likely become simply boring. JUnit, by this point, is old hat– it was super interesting almost a decade ago and when 4.0 came out it was something to chat about, but for the most part, there isn’t much more to say about unit testing in general (for evidence of this, read InfoQ.com’s posting and the subsequent comments dubbed “JUnit Still Not Dead“). Sure, few books regarding JUnit have been published lately and Google’s trends seem to indicate that no one searches on JUnit. But guess what? I don’t need anymore copasetic books on JUnit– I’ve read them and I’ve got enough knowledge now on how to properly utilize it. I have zero need to go to JUnit’s website either– there’s nothing new there. In fact, in some cases, people have moved on to other frameworks, like TestNG (at least one person, other than me, is also using easyb!).

The reality of the Java market though, is that there is an entire throng of people who didn’t (or couldn’t) jump on the JUnit bandwagon all those years ago– this crowd is largely maintaining enterprise applications that are, simply put, incredibly hard to unit test, man. In these organizations, I have found that, more often than not, this is where the battle for tried and true unit testing is being lost.

In fact, Andrew correctly quoted me as stating in response to why I don’t implement a lot of TestNG solutions for companies:

most organizations do so little unit testing, if any, that I stick with the simple, well-known xUnit tools, so as not to create confusion. Most organizations are just not ready to learn anything more than basic unit testing — if that.

Many of these companies are the entire reason why there is a Java based financial ecosystem. They are why products like Websphere exist. They are why products like JBuilder existed. They are also the same companies that companies like Agitar hoped would buy their products.

These companies employ a lot of trippin’ developers. These companies have many projects that are huge. Unit testing for these companies is like trying to eat an elephant– you can start with one bite, but the overall task is daunting! When people, who work on these projects, hear evangelists bang the TDD drum, many are left scratching their heads– “how do I write a unit test for an application that has more dependencies on external systems than I have figures on both my hands? It would take me longer to handle the dependencies than to just code the feature.” (True, there is folly in this statement, however, this statement is uttered daily across the globe, man.)

These comments and this line of thinking by people faced with maintaining these code bases on a daily basis then logically answers the question of why would someone assert that unit testing “seems to offer little value” and evangelism “has become so overbearing that it makes unit testing as a whole unappealing”– for these folks, the strict term unit testing is doomed.

Don’t get me wrong, it isn’t that unit testing is impossible for these code bases and these teams. I’ve made a career of assisting in this arena; however, this is no easy task. It takes years to effectively introduce cultural change that can yield disciplined unit testing across an organization. In fact, in these situations, you can’t introduce unit testing alone– to effectively gain the manifold benefits of proper unit testing, you need an entire infrastructure to support it– namely, you need continuous integration, which means you need predictable builds.

Think about it for a second– unit testing is the elephant in the room. You’ve just been asked to eat it. But you can’t just take a steak knife and fork and start eating– the elephant is still alive looking right at you. No, you’ve got to first kill it, cut it up, cook it, etc. No wonder few people eat the elephant. Burger King is around the corner! No wonder unit testing often times seems doomed. We have a QA team that finds bugs!

Indubitably, these development teams are forced to rely on late cycle testing or at best, in the short term, can of course build up a hip suite of higher level tests. As a matter of fact, this is probably the best place to start! Can’t isolate that Account object for unit testing? No problem, bite the bullet and code an integration test– just make sure you realize you’ve got to handle the myriad dependencies associated with that business transaction (think a properly seeded database, etc).

As I said, if unit testing, as it is defined within the context of TDD, is an elephant for you and your organization, then it

is likely to remain a niche solution, found at organizations that really understand its value and progressively adopted by sites that can no longer stand the long debug cycles.

The answer to most questions depends on your point of view– if you are working on a team that has embraced agile principles, unit testing is alive and well. It’s a healthy practice that when questioned brings extreme consternation to those who’ve drank the Kool-Aid.

If you find yourself working on a legacy code base, your answer might be somewhat different– indeed, unit testing in these cases is not as easy as downloading JUnit and coding away. It’s a sizable elephant that a culture has to collectively figure out how to eat. And that takes time, commitment, and a lot of discipline. If you can’t get a handle on those three aspects, then yes, unit testing is doomed. Can you dig it, man?

You might get a thrill out of writing Ajax applications (along with wearing bell bottoms), but developer testing them is totally bogue, man. This article examines the inherent challenge of testing hip asynchronous Web applications (especially when it comes to developer testing them early). Check out this month’s “In pursuit of code quality” article, entitled “Unit testing Ajax applications” and find out why it’s easier than expected to tame this particular code quality dragon with the help of the hip Google Web Toolkit.

Don’t forget to let it all hang out at the “Improve Your Java Code Quality” forum while you are at it, man!

I’m finding more and more people are using TestNG and JUnit 4, so I’m curious to see what this copasetic poll brings. This is, obviously, Java specific and does make the assumption you actually write tests, man– of course, you can always select the last option if that’s you.

Also, if you are using another hip framework not listed, I’m interested in hearing about it! Leave a comment, man.

As always, many thanks for your participation!

One of the hippest things about Google’s Web Toolkit is that you can write JUnit tests that can verify asynchronous server side behaviors. What’s more, your copasetic JUnit tests can also be run via Eclipse (not to mention a build process like Ant, etc), which has the effect of decreasing the time between when you code a feature and when you can verify it actually works as expected.

In order to run your GWTTestCase classes in Eclipse, however, you need to do a few steps, otherwise, you’ll get a bunch of nasty things not found errors. Accordingly, to configure Eclipse’s bag to successfully run your JUnit tests, you need to do three things:

1. Create a configuration profile via the Run menu item to launch your JUnit test. Because it’s my bag, I like to create an individual profile for each test, hence, you’ll need to have a fully qualified test class specified. Additionally, ensure the test runner is JUnit 3.
   
2. In the Arguments tab, add -Dgwt.args="-out www-test" to the VM arguments section.
   
3. Lastly, in the Classpath tab, you’ll need to add a few User Entries– namely the directories where your source code and test code lives.
   
4. • This is done by selecting the User Entries item and clicking the button labeled Advanced, then selecting the Add Folders option and then actually selecting the desired folder. It is actually quite easy.

After that, you’re good to go to run those JUnit GWT tests, man!

Creating copasetically Ajax enabled web applications with Google’s Web Toolkit is quite easy due to the ability to write these applications in Java rather than JavaScript. What’s more, GWT applications can be tested via JUnit — actually, to be precise, the backend of an Ajax application can be tested via JUnit. In essence, JUnit GWT tests shouldn’t attempt to validate user actions by clicking buttons, etc, but rather should verify the logic behind those user interactions.

For example, if by clicking a button, an asynchronous call is made to retrieve information from a backend system, a copasetic JUnit test can be written to validate the asynchronous aspects work as designed. This means you should approach writing GWT applications with testing in mind. It is quite easy to write a GWT application that can only be functionally tested– it takes some though as to how you’ll craft it so you can validate logic without crowding it with UI handling.

Regardless of how you actually end up implementing your test, you need to do three things. In fact, the first two steps, if done incorrectly, will cause you much frustration as your tests are guaranteed to fail (even though things compile and you logically write a correct test).

First, in order to create a valid (and by derivation, hip) GWT test case, you must create a class that extends GWTTestCase (or some derivation). What’s more, this test class must live in the same package as the module you’re testing, plus, the test class’s name must follow the pattern of “Test<your module’s class name>.”

For example, if your module is named OrderStatus, then your test case will be named TestOrderStatus. Remember, the test has to be in the same package as well. If OrderStatus is in com.acme.t55.client, then the test class will be logically named com.acme.t55.client.TestOrderStatus.

Second, you must implement the getModuleName method, which returns a String representing the fully qualified XML file name that defines your module in GWT. For example, in the example above, there is a folder structure that is com/acme/t55 in which an XML file lives named OrderStatus.gwt.xml. In this case, the module’s name is com.acme.t55.OrderStatus. Your getModuleName method would look like this:

public String getModuleName() {
 return "com.acme.t55.OrderStatus";
}

As you can probably ascertain man, the first two steps are easy to get wrong; however, things will compile just fine. These are basically semantic requirements of GWT’s GWTTestCase. Get these two incorrect and you have no hope of actually running a successful test.

Finally, step three is to implement a test method, which of course has a name that begins with “test”– this is back to basic pre-JUnit 4 rules. One thing to keep in mind, however, is that server side asynchronous logic’s bag is asynchronous, which means writing normal test code won’t fly– JUnit will cut out before things finish executing.

As such, the GWT comes with a Timer object that allows you to write assertion logic for asynchronous code within a separate thread. Can you dig it?

One of my favorite features of TestNG is its hip parametric testing ability, which allows you to create generic test cases and then vary the test values– you can use parameters from XML files or even use the DataProvider feature for a more rich parameter type. In fact, for awhile, because it’s my bag baby, I’ve been espousing TestNG’s out of the box parametric testing features as a reason to use TestNG as a opposed to JUnit for higher level testing. JUnit 4 , however, now supports parametric tests– and you’ll find that its parametric testing is rather similar to TestNG’s DataProvider.

For example, in TestNG, if I’d like to create a generic test and vary its parameters, I have to do three things:

1. Create a generic test whose parameters are the parameterized values
2. Create a DataProvider method, which feeds the values for the test
3. Link the DataProvider method to the test via the @Test annotation

Hence, I can create a copasetic generic test method as follows:

public void verifyHierarchies(Class clzz, String[] names)
 throws Exception{
  Hierarchy hier = HierarchyBuilder.buildHierarchy(clzz);
  assertEquals(hier.getHierarchyClassNames(), names, "values were not equal");
}

Then I can create a feeder method as follows:

@DataProvider(name = "class-hierarchies")
public Object[][] dataValues(){
 return new Object[][]{
   {Vector.class, new String[] {"java.util.AbstractList",
      "java.util.AbstractCollection"}},
   {String.class, new String[] {}}
  };
}

Note how I have to declare a name for DataProvider, in my case, I dub it class-hierarchies. I can now link the two methods by using the @Test annotation and setting the dataProvider value to the name of my feeder method:

@Test(dataProvider = "class-hierarchies")

That was fairly disco, no? JUnit 4 takes a somewhat similar approach that requires a bit more legwork though:

1. Create a generic test that takes no parameters
2. Create a static feeder method that returns a Collection type and decorate it with the @Parameter annotation
3. Create class members for the parameter types required in the generic method defined in step 1
4. Create a constructor that takes these parameter types and correspondingly links them to the class members defined in step 3
5. Specify the test case be run with the Parameterized class via the @RunWith annotation

If I take the same code above and rework it to use JUnit 4 parameterizations, I first must create the generic test:

@Test
public void verifyHierarchies() throws Exception {
 Hierarchy hier = HierarchyBuilder.buildHierarchy(clzz);
 assertEquals("values were not equal",hier.getHierarchyClassNames(), names);
}

Second, I need to create a dynomite feeder method, which functions much like TestNG in that it requires an Object array with matching parameter types.

@Parameters
public static Collection hiearchyValues() {
 return Arrays.asList(new Object[][] {
  {Vector.class, new String[] { "java.util.AbstractList",
     "java.util.AbstractCollection" } },
  {String.class, new String[] {} } });
}

Note how this method is decorated with the @Parameter annotation, man. Next, because the parameters are of types Class and String[], I create two class members:

private Class clzz;
private String[] names;

Step 4 requires I create a constructor, which links values:

public HierarchyBuilderParameterTest(Class clzz, String[] names) {
 this.clzz = clzz;
 this.names = names;
}

Lastly, make sure you specify at the class level that this test be run with the Parameterized class like so:

@RunWith(Parameterized.class)

As you can see, JUnit makes you jump through a few more hoops, yet the fundamental requirements are quite similar to TestNG’s DataProvider feature. When push comes to shove, I still find TestNG’s semantics much simpler, but it’s nevertheless a disco feature to find in JUnit 4. Dig it?

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!

Verifying XML documents has always been the strength of XMLUnit; however, I’ve often found that this JUnit extension is challenging when trying to verify specific portions of a hip XML document. Sure, XMLUnit supports XPath , but XPath is somewhat of a pain (especially if you aren’t an adept XPather).

For example, given the following copasetic XML document, I’d like to verify the exact value of the name attribute of the first Class element.

<DependencyReport date="Wed Dec 31 21:30:00 EST 1969">
  <FiltersApplied>
    <Filter pattern="java|org"/>
    <Filter pattern="junit."/>
  </FiltersApplied>
  <Class name="com.vanward.test.MyTest">
    <Dependency name="com.vanward.resource.XMLizable"/>
    <Dependency name="com.vanward.xml.Element"/>
  </Class>
  <Class name="com.xom.xml.Test">
    <Dependency name="com.vanward.resource.XMLizable"/>
    <Dependency name="com.vanward.xml.Element"/>
  </Class>
</DependencyReport>

Using XMLUnit and XPath, if you’d like to verify that the first Class element’s name attribute value is com.vanward.test.MyTest, you could use the following disco XPath expression:

//Class[1][@name='com.vanward.test.MyTest']

This XPath expression, in concert with XMLUnit, yields the following JUnit test case that must extend XMLUnit’s XMLTestCase due to the call to assertXpathExists:

public void testToXML() throws Exception{
 BatchDependencyXMLReport report =
   new BatchDependencyXMLReport(new Date(), this.getFilters());
 report.addTargetAndDependencies("com.vanward.test.MyTest",
    this.getDependencies());
 report.addTargetAndDependencies("com.xom.xml.Test",
    this.getDependencies());

 assertXpathExists("//Class[1][@name='com.vanward.test.MyTest']",
                report.toXML());
}

In order to verify exact portions of an XML document within XMLUnit, I must have a working knowledge of XPath and must extend XMLUnit’s XMLTestClass. Also too, debugging XPath expressions with XMLUnit isn’t exactly easy either– you end up relying on test case successes or failures to ascertain if your expression is actually valid (but what a great way to verify them, I suppose!). Clearly, verifying exact XML values in XMLUnit is possible, but it could be easier.

Using Groovy, traversing XML documents and obtaining values is, in my opinion, amazingly simple and is much more easy to grasp than XPath. For example, verifying the same exact attribute value can be done as follows:

void testToXML() {
 def report = new BatchDependencyXMLReport(new Date(), this.getFilters())
 report.addTargetAndDependencies("com.vanward.test.MyTest",
    this.getDependencies())
 report.addTargetAndDependencies("com.xom.xml.Test",
     this.getDependencies())

 def doc = new XmlSlurper().parseText(report.toXML())
 def clazzes = doc.Class
 assertEquals("class name should be com.vanward.test.MyTest",
   "com.vanward.test.MyTest", clazzes[0].@name.text())
}

In this example, you only need to work with Groovy’s XmlSlurper class and you’re able to traverse XML nodes as if they are a call graph. As you can see, after the XmlSlurper class is initialized with my document, I am able to grab a reference to the collection of Class elements by asking the root node directly by specifying the element name, which, because it’s my bag, is Class.

Once I have this collection of elements, I can simply reference them similar to XPath, but in Groovy’s case, the access method is 0 based (which is array based access that you learned in CS101). If you look at the first XPath example, it’s 1 based (see the [1] reference?). Accessing attributes is also similar to XPath via the @ symbol and obtaining their value requires the text call.

Given these dynomite semantics, the same XML navigation from the first code example is a much more natural clazzes[0].@name.text(). What’s more, the beauty here is that you’re not dealing with Strings either. Granted, the two examples are slightly different– in the pure Java one, due to the limited API of XMLUnit, I’m forced to assert that an expression exists and in Groovy, I can assert that a value exists. The latter feels more flexible to me.

Using Groovy’s innate XML handling ability means XPath isn’t required. Which is easier to comprehend to you– //Class[1][@name='com.vanward.test.MyTest'] or clazzes[0].@name.text()? The next time you find yourself wanting precise access to portions of an XML document, put Groovy to the test– you’ll find it quite groovy. Dig it?