The Disco Blog Welcome Guest | Login or Register

At a copasetic CITCON session in Dallas recently, Martin Fowler mused on the “future of build languages” and suggested that due to Ant’s inability to be richly expressive (think conditionals, looping, etc) that future build platforms will be modeled as native domain specific languages much like Rake is in the Ruby world (or SCons is in the Python world). Note, Ant is a DSL, but it is expressed in XML not Java, man.

Because it’s my bag, I largely agree with Martin, however, given Ant’s deep penetration within the Java market, compared to Maven (which, I think is one step closer to a Rake-like build platform for Java) I wonder if the Rake model can come to fruition and obtain any reasonable mindshare. Sure, there are hip projects underway like Raven (which combined forces with JRake recently), which does a number of useful things such as compilation, testing, etc, but ultimately, as Ant is the de facto build platform for Java, practically every tool out there bundles an Ant task. If you want to use Raven and would like to generate a report with JavaNCSS, for example, you might have to write some custom Ruby code to fire the JavaNCSS process off. Hopefully, the increased velocity of development on JRuby will alleviate this issue as it appears JRake makes use of Ant tasks.

It seems to me that if a more DSL-like platform is going to gain any mindshare within the Java community, it’ll have to take advantage of the rich infrastructure present within Ant (Maven did this though and hasn’t overtaken Ant by any means). One such project is Groovy’s Gant, which enables you to specify builds via Groovy rather than XML. Groovy provides expressiveness and is native to the JVM; however, given the history of Java build platforms, I suppose Gant’s adoption will lag behind Maven by a long shot, man.

Interestingly, a few individuals suggested that some of the issues associated with Ant were not necessarily related to Ant, but to people’s usage of the tool. This made me remember an excellent article published a number of years ago that largely still holds true: “Top 15 Ant Best Practices.”

Ultimately, Ant is the de facto standard for building Java applications. Like it or not, it works for 90% of those that attempt to employ it. There will be innovative and clearly more flexible build platforms that’ll pop onto the scene, but displacing Ant is much like thinking that Macs or Linux will overtake Windows installations (in the near future). Displacing these kinds of market leaders takes seismic paradigm shifts (like we are currently seeing with Disco music).

What’s after Ant? Well, we’ve seen what’s next: it’s Rake (or Raven or Gant), but for Java, the vast majority of the community doesn’t appear to care. That’s so establishment.

• 8 reasons why you SHOULD track every bug- Charles gives “8 reasons why a bug list is more than just a to-do list.”
• Javascript and CSS Compression in MSBuild- Not a bad idea, man.
• Green Bar of Shangri-La- “this article could be considered to be a cautionary note on over-reliance on unit testing, or on the mistaken belief that unit tests can prove that a system is bug-free” — well written, man!
• assertThrownException- David Saff describes imposterization using JUnit and assertions. Well done.
• VS2005 Template for listening to TFS Events- This template is quite helpful.
• The Way of Testivus - Unit Testing Wisdom From An Ancient Software Start-up- “An ugly test is better than no test” — that’s the truth, brother!
• Unit Testing Tips from Google- These guys probably know a few things about the subject, right?

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?

Because it’s my bag, I pointed out recently that copasetic coverage tools (like Cobertura) can inadvertently hide defects by reporting specific lines of code as covered. But, while I often use Cobertura in my examples, I have found that Emma is fairly smart in its reporting of code coverage values. As such, I often find myself running both hip tools for projects.

For example, the same branchIt method from my previous posting is displayed slightly different in Emma as shown below. Specifically, note line 10– it’s colored yellow in an attempt to show that not all conditions of the conditional were executed.

(Click the picture to view a larger version)

While Emma probably reports coverage more accurately (note, it reports block coverage), I still find Cobertura’s reports more aesthetically pleasing. In truth, I’m a firm believer that coverage reports are more effective at telling you what’s not covered; accordingly, both tools are quite accurate in this regard. Can you dig it, man?

The week’s bag in once place, man.

• Unit or Functional Tests?- This is a hip read on Cedric’s blog as well as the comments on Artima.
• Unit testing needs time?- Good thoughts on the cost of fixing defects.
• Team Foundation Source Control Guidelines …- TFS guidelines are always helpful.
• Test your Spring - Hibernate Applications using Unitils- A new testing framework if you’re focused on Spring and Hibernate.
• Unit testing Javascripts in Java 6 – Getting started with the javax.script api- Not a bad idea.
• VSTS Testing: Using Fiddler to record VSTS web tests- Fiddler sounds interesting– are you using it, man?
• FindBugs - Writing custom detectors (Part 1)- Daniel’s done a good job showing you how.
• Conformance Testing for Java ME- “It is difficult to ‘write once run everywhere’ in the Java mobile phone market”– you got that right!
• Why moving work offshore fails- What do you think, man?

As I’ve written about before, code coverage numbers can be misleading. 100% line coverage and 100% branch coverage doesn’t necessarily mean your code is defect free– all it means is that that code was touched. In fact, code coverage values are far more effective at telling you what’s not covered by a test, man.

There are actually quite a few hip different ways that coverage values can be misleading. One particular coding construct can easily mislead the unsuspecting eye: the short-circuit operator. These operators, such as the short-circuit AND (&&) and OR (||) are quite handy in conditionals. For example, here’s a fictional code snippet with a copasetic OR short-circuit operator in the first conditional.

public void branchIt(int value){
 if((value > 100) || (HiddenObject.doWork() == 0)){
  this.doIt();
 }else{
  this.doItAgain();
 }
}  

In the snippet above, both the doIt and the doItAgain methods aren’t particularly important– what’s key here is the second part of the if conditional. Let’s imagine HiddenObject is a 3rd party API call, an object in another package, etc– the point being, you don’t necessarily know how doWork does its work, you just know that because it’s its bag that if it returns 0 it is a valid condition.

It just so turns out that the doWork method on the HiddenObject method isn’t perfect– it can throw an exception. I’ll force one, but the scenario demonstrates a trippin’ point.

public static int doWork(){
 throw new RuntimeException("surprise!");
}

Thus far we know that if the doWork method is executed an exception will be thrown. Imagine I don’t know that though. Let me write a quick test (via JUnit) to make sure things are working.

public final void testBranchIt() {
 AnotherBranchCoverage clzzUnderTst = new AnotherBranchCoverage();
 clzzUnderTst.branchIt(101);
}

When I run this test, things work fine. I can even check out the coverage values as reported by Cobertura.

Not bad– I’ve got reasonable line coverage here and 100% branch coverage. It turns out the 100% value for branch coverage is a slight defect within Cobertura, but regardless, I’ve got copasetic coverage, don’t I? Check it out, man, the if statement was touched! Because of the short-circuit OR, I triggered a true condition via the 101 value; accordingly, the second clause was short-circuited. The 75% line coverage makes sense too– I failed to execute the else block, hence the other method within the class wasn’t touched and the line coverage value was accordingly deducted.

As you can see, coverage reports are hip in ascertaining what’s not tested (which, in this case, would practically force me to execute the 2nd condition in the if) but don’t depend too heavily on them telling you what’s tested. Otherwise you could end up short-circuiting yourself into a false sense of security…or is that coverage?

Without further ado:

• How to Build Good Software? Have a good build process- Now you’re talking friend!
• Embedded Integration Testing of Web Applications- Testing first is often quite challenging, but Johannes Brodwall takes a shot at it in this Java.net article.
• Dell XPS Showing JUnit Status- A great example of intuitive feedback in action. Well done, man!
• Static analysis tips for success- The Enerjy team’s got some good advice here. Nice to see another company joining the corporate blog fray.
• .NET Memory Leaks- Memory leaks on the .NET platform? Noooo, really?
• InfoQ Interview: David Hussman on Coaching Agile Adoption- David Hussman is a cool cat– he has a lot of interesting things to say, man.
• TeamCity 2.0: Eclipse support, improved IntelliJ IDEA plugin- TeamCity is quite the tool.
• The Silver Bullet- Well said, Kirk!
• Shipping unit tests with your shrinkwrapped software- If aren’t already doing this, here’s a good article describing why.

In Selenium, you can author hip tests programmatically using the language of your choice or via Fit-style tables. From a testing standpoint, the process and results aren’t much different regardless of which one you choose; however, with table driven tests, fixtures aren’t necessarily present. You have to concoct your own.

For example, if I want to use a fixture when programmatically building Selenium tests, I just plug into which ever copasetic test framework happens to be driving my Selenium code– I can use TestNG, JUnit, heck anything I want to– Selenium doesn’t really care. The point being though is that if I use TestNG, for instance, I can then put reusable setup code into a fixture. In the case of web testing, I may need to set up some database records before I run a bunch of acceptance tests.

Conversely, table tests in Selenium don’t hook into an existing test framework– they exist on their own and Selenium acts according to the hip commands placed in a particular table. For example, below is a Selenium test that verifies that one can create words in an online dictionary. The table reads quite easily– the far left column represents browser commands. The middle column corresponds to how the first column should act. In row one, the command is to open the web page located at ../CreateWord.html.

The far right column in a Selenium table test represents input data corresponding with a command. In the second row from above, the first column instructs the browser to type, in the input element whose id is word, the string clepsydra. Rows three and four are similar– three selects the Noun element in a drop down list whose id is partOfSpeech.

This test is fine and dandy (plus copasetic), however, it suffers from a lack of logical repeatability– if this test is run twice, the second test will most likely fail (assuming the database is designed to constrain unique values, like words in a dictionary). What I need, of course, is a way to ensure that this test can be run in a repeatable manner; accordingly, this is where a framework like DbUnit shines.

DbUnit essentially is a fixture framework that manages database data so that you don’t have to during testing. This is a hip point– DbUnit ensures a database is ready for tests– either by inserting look up data or pre-requisite rows before a test is run. What’s more, DbUnit can also remove data after a test. In turns out that DbUnit can both insert desired data and remove test data at the same time before a test is run, thus obviating the need to run database logic after a test completes too.

Putting the database in a clean state before I run a test (like the Selenium above) is fine and dandy; however, it doesn’t really help me yet as I need some way of invoking DbUnit via my Selenium table test. Because Selenium is ultimately a web testing framework that drives a browser, I can essentially force a fixture via embedding fixture logic in a web page. This is where a diet rich in Selenium, by the way, can start to get Groovy.

Groovy shines as a medium for creating hip applications quickly– I use this fine language all the time to knock simple stuff out. Accordingly, with Groovy, because it’s my bag, I can create a quick and dirty (but albeit clearly useful) Groovlet that uses DbUnit to put the database in a known state before I run any of my Selenium tests; what’s more, because the Groovlet is a web resource, I’ll create a Selenium table test to invoke it before running the other tests.

Groovlets do require a slight container configuration tweak and the addition of Groovy’s uber jar to the associated web application’s classpath; however, once you’ve taken care of those two requirements, you’re good to go to drop in Groovy scripts that are executed as web resources. What’s more, Groovlets don’t have to follow any associated framework pattern– you don’t have to implement a doGet method or anything like that; in fact, you don’t have to even define a class– just code away in a normal script and that code will be executed within the context of a Servlet.

For example, the following groovy Groovlet does exactly what I need and is a fixture that ensures I can run the create word test from above in a repeatable manner by employing DbUnit.

import org.springframework.context.support.ClassPathXmlApplicationContext
import org.dbunit.database.DatabaseConnection
import org.dbunit.dataset.xml.FlatXmlDataSet
import java.io.ByteArrayInputStream
import org.dbunit.operation.DatabaseOperation;

def scontext = new ClassPathXmlApplicationContext("spring-config.xml")
def datasource = scontext.getBean("dataSource")

def data = """<?xml version='1.0' encoding='UTF-8'?>
<dataset>
 <word WORD_ID="1" SPELLING="pugnacious" PART_OF_SPEECH="Adjective"/>
 <definition DEFINITION_ID="10" DEFINITION="Combative in nature; belligerent."
    WORD_ID="1"
    EXAMPLE_SENTENCE="The pugnacious youth had no friends left to pick on."/>
 <synonym SYNONYM_ID="20" WORD_ID="1" SPELLING="belligerent"/>
 <synonym SYNONYM_ID="21" WORD_ID="1" SPELLING="aggressive"/>
</dataset>
"""

def dataset = new FlatXmlDataSet(new ByteArrayInputStream(data.getBytes()))
def conn = new DatabaseConnection(datasource.getConnection())
DatabaseOperation.CLEAN_INSERT.execute(conn, dataset)
conn.close()

println "fixture executed successfully"

Because the web application being tested uses Spring, the Groovlet obtains a reference to a copasetic DataSource object (that is consequently used by associated Hibernate code) in order to obtain a connection to the underlying database. Next, a String instance is created that contains XML representing the data I want placed in the database before my tests are run. DbUnit has a few different formats for data representation; however, I find that the FlatXmlDataSet format is most intuitive.

Using DbUnit’s API, I then insert the corresponding XML in the dataset String. Note that because it’s my bag baby, I use DbUnit’s CLEAN_INSERT command, which first deletes all existing data and then inserts the data found in the XML. This means I don’t need to worry about a tear down fixture– the set up removes old data and puts in new requisite data. Lastly, the connection is closed and the fixture is considered complete. Not bad, considering the fixture look 5 minutes to code and about 10 lines of code, eh?

From Selenium’s standpoint, I don’t really need to do anything but create a table test that opens this page before running any tests, man. Then I need to update my suite file and ensure that the fixture is the first URL hit before any tests are run.

Now I’ve got a repeatable suite of Selenium tests– and all it look was a little help from Groovy and DbUnit. Dig it?

Here’s the bag, baby:

• NHibernate Best Practices with ASP.NET, 1.2nd Ed.- Billy McCafferty suggests using NDbUnit for testing– I like that advice!
• Simple NHibernate Example, Part 5: Repository Testing- Nelson Montalvo uses a customized version of NDbUnit, however.
• 1st Workshop on Refactoring Tools- If you are going to be in Berlin on July 31st, you should attend, man.
• Teamprice 2.1 Released- Using Eclipse with VSTS? Not a problem!
• Bill Gates Confronts the Future in 1989- Interestingly enough, in 1998 Mr. Gates remarked that two years was a long time to complete a project. Two years. Vista took five.
• Approach to Optimization- Some good advice here on code optimization.
• Reinventing Code Review- More good advice on how to conduct a code review.
• Comparison of Java ME unit testing frameworks- Testing code on mobile devices? This is your page, man.
• Code Craft: The Practice of Writing Excellent Code- This book has been on my reading list for some time– looks like I should move it up the queue.