The Disco Blog Welcome Guest | Login or Register

A little late:

• Screenshots of failing GUI tests in JUnit report- Keep up the great work, FEST team!
• Is your code worthless?- Ummm, maybe yours is.
• AJAX application testing- David Herron has some thoughts here– thanks for reading the developerWorks article, man!!
• Book Excerpt: Continuous Integration means Continuous Testing- Wow, what a great book– I recommend you pick up a few copies for yourself.
• Glean gets a dashboard- Glean sure does look hip.
• The Build Pipeline- Great advice in this one.
• Unit tests are a drop cloth- Well said, Alex.

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!

Here you go:

• Pardon My French, But This Code Is C.R.A.P.- as usual, Artima has a great thread going here.
• How Code Queries Improve Software Quality- speaking of Artima, here is a good read, man.
• JUnit 4.4 Released- based upon the response of the test framework poll, it appears a lot of you will download this version!
• Test-driven GUI development with FEST- isn’t the name FEST just, well, hip, man?
• PMD: Automated source code analysis and bug detection- one of my all time favorite projects.
• Cool tool for requirements test coverage- cool, requirements, and test coverage in the same sentence? One has to read this!

Kohsuke Kawaguchi (the copasetic creator of Hudson) has created a hip Gant plugin for Hudson, which makes it amazingly simple to execute Gant builds within the context of a CI environment. If you haven’t tried out Hudson, you are in for a pleasant surprise– it is almost effortless to get up and running. Plus, now that you can integrate Gant without a smudge of elbow grease, I’d say Hudson is, well, um, groovy, man!

Some good reads this week, man!

• Dirt Simple Mock Objects In Groovy- Scott Leberknight is down with Groovy, man! I guess that makes him a groovy man?
• Asserting architectural soundness article and podcast- If you can’t get enough of Paul’s article, just listen to the podcast.
• From Maven to Buildr- Hopefully the transition didn’t take the entire flight, Jim.
• Patterns & Practices: Performance Testing Guidance for Web Applications- Great quote from the late nineties by Victoria’s Secret, right before they broadcast a live internet show to thousands of drooling geeks (myself included)– “Who needs performance testing?”
• PMD 4.0rc2 released - Java 1.5 by default- Way to go, PMD team! Check out Tom’s newest book too.

Don’t forget to take part in the latest scientific study related to test frameworks.

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!

If you are in New York City area on July 18th, I’ll be speaking at the NYJavaSIG, specifically about Groovy, baby. Much like the June double header in Princeton, I’ll be teaming up with Jeff Brown (who is a Grails committer) and presenting an overview of the Groovy platform with a focus on Builders, Groovlets, and GroovySQL to name a few of Groovy’s copasetic features.

It promises to be a hip night– see you there! I’ll be brining a copy of GIA as well. Who’s gonna win it, man?

A few months back, Scott Davis, the editor in chief of aboutGroovy.com interviewed me regarding all things Groovy, man. It’s amazing that I only managed to get in one hip word during the event– I’ll have to work on that.

If you don’t have anything better to do for roughly 14 and 1/2 minutes, check it out! Don’t forget to pick up a few copies of the Groovy book while you are at it, baby!

Links for your reading pleasure:

• Groovy Mocks- The bees knees, man.
• Programming with “Duh” Typing- As always, Artima has a hip thread going here with links to plenty of articles related to dynamic and static language comparisons.
• Ant Utility For Build Analysis- Want to find out why your Ant builds are taking too long? Hint, check your tests, man (assuming you have some).
• Rethinking Design Patterns- A good read this one is.
• The books that influenced me- Speaking of influential books, Jeremy lists a few!
• Agile Measurement - A Missing Practice?- Oh the horror…fraught with plugs too.
• Observations on TDD in C++- C++ can make TDD challenging, man
• CruiseControl.NET Demo- CC.NET is a copasetic tool, indeed.

Without a doubt, DSLs are all the rage these days (in fact, if their popularity continues to skyrocket, they’ll easily become more hip than shiny clinging Lycra stretch disco pants in hot strident shiny colors with stretch sequin bandeau tops…as if, man). In particular, Dynamic languages (like Groovy and Ruby) gain a lot of their credibility through their facilitation of creating DSLs easily. There are certainly different levels of sophistication when it comes to defining a DSL too.

For example, Rake, Ruby’s make is essentially a DSL for building applications with a simple, yet powerful syntax, man.

task :name => [:dependencies] do
  #stuff
end

Because Rake files are Ruby files, you can do a whole lot of magic with Rake that, for example, isn’t quite possible with XML (hence, some people find themselves frustrated with Ant). Groovy, too, has brought to bear the power of DSLs in defining an alternative to Ant, dubbed Gant, which has a similar syntax for building applications:

target (target-name:target-description) {
  //do stuff
}

The ability to create DSLs involves a number of different techniques as well (depending on the sophistication of the DSL under development); however, with Groovy, you can create an intuitively simple one using the BuilderSupport object, man.

For example, let’s imagine you’ve been tasked with building an astronomy application for students to explore the relationship between planets and their associated moons (or satellites) and you need a way for Astronomy professors to define a planetary system (for a given planet, there are x moons with differing properties). You could create a text file or an XML file and go from there (but that wouldn’t be copasetic these days would it?) or you could define a mini-language, if you will, that enables a domain expert to define a planet and its associated satellites.

After working with your clients (in this case, wacky professors with two left shoes on), you decide on a simple structure that facilitates defining a planet (along with some properties of it), which supports attaching a series of children elements, which represent moons (and are also defined with the same properties as a planet).

PlanetName(Distance:x, OrbitPeriod:y, Radius:z){
  MoonName(Distance:d, OrbitPeriod:o, Radius:r)
  // 0..N moons possible
}

In the structure above, distance is assumed to be kilometers, the orbit period is in earth days, and the radius is also in kilometers.

For example, given the structure above, one could define Jupiter and a sampling of its moons as follows:

Jupiter(Distance: 778412020.00, OrbitPeriod: 4330.60, Radius: 71492.00){
  Callisto(Distance: 1883000.00, OrbitPeriod: 16.69, Radius: 2403.00)
  Ganymede(Distance: 1070000.00, OrbitPeriod: 7.15, Radius: 2634.00)
  Pasiphae(Distance: 23500000.00, OrbitPeriod: -735.00, Radius: 18.00)
  Sinope(Distance: 23700000.00, OrbitPeriod: -758.00, Radius: 14.00)
}

The good news at this point is that the hard work is already done– the simplistic DSL has been defined and is, luckily, quite easy in structure. The key to finishing the job is via Groovy’s BuilderSupport class, which is a normal Java object that you can extend and then implement a series of template methods that are executed a specific points. You’ll also have to consider how one obtains the final hip product– in my case, I’d like a PlanetarySystem object (which was defined in a previous post). Accordingly, I’ll create an instance of this object upon the discovery of the first node when someone invokes the builder instance. Then for each child node, I’ll create a Moon instance and add it to the PlanetarySystem.

My initial object looks like the following code snippet– note this is a normal Java object (as opposed to a Groovy one).

public class PlanetarySystemBuilder extends BuilderSupport {
 private PlanetarySystem system;

 //...template methods 

 public IPlanetarySystem getPlanetarySystem() {
  return this.system;
 }
}

As you can see, the main point of the code above is the fact that after the builder has been created, one can obtain an instance of a PlanetarySystem via the getPlanetarySystem method.

The BuilderSupport object has a number of abstract methods that you must implement, however, as it turns out for my simple DSL, I only needed to add meat to one method– the createNode(Object name, Map map), which is invoked anytime a node is found that has a format like name(map), such as Io(Distance: 422000.00, OrbitPeriod: 1.77, Radius:0.00). It also doesn’t matter, in this Age of Aquarius, at which depth a particular node like this is found– you can actually determine depth by watching corresponding nodeCompleted methods invoked.

Since my simple little language doesn’t have too much variance in structure, it turns out that implementing the createNode method is sufficient for my needs:

protected Object createNode(Object name, Map map) {
 if (this.system == null) {
   this.system = new PlanetarySystem((String) name,
       ((BigDecimal) map.get("Distance")).doubleValue(),
       ((BigDecimal) map.get("OrbitPeriod")).doubleValue(),
       ((BigDecimal) map.get("Radius")).doubleValue());
 }else{ // must be a moon
   Moon moon = new Moon((String) name,
       ((BigDecimal) map.get("Distance")).doubleValue(),
       ((BigDecimal) map.get("OrbitPeriod")).doubleValue(),
       ((BigDecimal) map.get("Radius")).doubleValue());
   this.system.addMoon(moon);
 }
 return name;
}

As you can see from the boss code above, the first parameter name (of type Object) represents the node’s actual name– either a planet or a moon. Basically, my logic is simple (which of course is probably a bit brittle, but good enough for now)– if the PlanetarySystem object is null (meaning the builder instance is new), then I assume that the first node is a planet and then all children are moons associated with that planet. The second parameter, map (of type Map) contains all the smokin’ pairs (y:x) in the node’s definition. If a value has a decimal (such as 19.13), BuilderSupport will create a BigDecimal instance and place it in the map with its related name (i.e. OrbitPeriod: 1.77).

With this method defined, I can then create an instance of my PlanetarySystemBuilder and start to define a system (i.e. a planet with its moons). For instance, I can create Jupiter (again) and a few of its moons as follows:

def builder = new PlanetarySystemBuilder()

builder.Jupiter(Distance:778412020.00, OrbitPeriod: 4330.60, Radius: 71492.00){
  Io(Distance: 422000.00, OrbitPeriod: 1.77, Radius:1815.00)
  Europa(Distance: 671000.00, OrbitPeriod: 3.55, Radius: 2634.00)
  Callisto(Distance: 1883000.00, OrbitPeriod: 16.69, Radius: 2403.00)
  Ganymede(Distance: 1070000.00, OrbitPeriod: 7.15, Radius: 2634.00)
  Pasiphae(Distance: 23500000.00, OrbitPeriod: -735.00, Radius: 18.00)
  Sinope(Distance: 23700000.00, OrbitPeriod: -758.00, Radius: 14.00)
}

Once the tripping builder has been defined, I can then ask for a built PlanetarySystem via the getPlanetarySystem; plus, I can even assert that things worked out:

def system = builder.getPlanetarySystem()
assert system.fastestOrbitingSatellite().getName() == "Io" : "builder didn't work"
assert system.closestSatellite().getName() == "Io" : "builder didn't work"

Of course, the next step would be to make the builder object a bit more robust– as defined it is brittle in a number of ways (forget a decimal and it’ll blow up, try and add another planet and you’ll see it as a moon, etc). After a few more test cases, I’ll be ready to refactor, man.

As you can see, builders in Groovy are a cinch to define– once you see how each neat-o template method is logically called upon the discovery of a node, you only need to figure out how to maintain state of what you’re trying to build– in my case, it turned out to be quite simple (one object with a collection as one of its properties). More intricate definitions, of course, will require a bit more muscle. The next time you find yourself dealing with a hierarchical structure, give Groovy’s BuilderSupport a shot. Dig it?