Griffon plugins walktrough: testing

Following the previous entry on Griffon's builder plugins I present before you a few options that can make your life easier when testing a Griffon application.

1. FEST

FEST stands for Fixtures for Easy Software Testing, it is an interesting project that includes a Swing module. It's fluent interface design plays very well with Groovy as it has been shown here and here. Resurrecting once more the WordFinder application from previous examples, this time as a full Griffon application here is how a regular FEST-enabled Griffon test looks like

import org.fest.swing.fixture.*
import org.testng.annotations.*
import griffon.application.SingleFrameApplication
import griffon.util.GriffonApplicationHelper

class WordFinderTest {
   private SingleFrameApplication app
   private FrameFixture window

static {
      SingleFrameApplication.metaClass.shutdown = { ->
         GriffonApplicationHelper.runScriptInsideEDT("Shutdown", delegate)
         delegate.appFrames[0].visible = false
      }
   }

@BeforeMethod void init() {
      app = new SingleFrameApplication()
      app.bootstrap()
      app.realize()
      window = new FrameFixture( app.appFrames[0] )
      window.show()
   }

@AfterMethod void cleanup() {
      window.cleanUp()
   }

// --== tests ==--

@Test
   void assertDefinitionPresent() {
      window.with {
         textBox("wordValue").enterText "pugnacious"
         button("findWord").click()
         label("answer").requireText "Combative in nature; belligerent."
      }
   }

@Test
   void assertNoWordPresentThenInvalidText() {
      window.with {
         textBox("wordValue").enterText ""
         button("findWord").click()
         label("answer").requireText WordFinderModel.TYPE_A_WORD
      }
   }

@Test
   void assertWordPresentThenUnknownWord() {
      window.with {
         textBox("wordValue").enterText "Ha77"
         button("findWord").click()
         label("answer").requireText WordFinderModel.UNKNOWN_WORD
      }
   }
}

The Griffon FEST plugin provides 2 new scripts:

create-fest-test: as the name implies it will let you create a new FEST test using a predefined template.
run-fest: this script runs all FEST tests and outputs a nice HMTL report, courtesy of TestNG.

2. Easyb

Easyb is one of those projects that make your job an enjoyable and fun experience once again. Easyb is a Behavior Driven Development framework for the Java platform that happens to leverage Groovy as the driving force behind a powerful yet simple to learn DSL for software testing. This plugin also adds a few new scripts:

create-easyb-story: creates a new Easyb story using a predefined template.
run-easyb: runs all Easyb stories and specifications, it can output reports in plain text and xml.

This plugin is actually a port of the Grails Easyb plugin, the porting task took a mere afternoon, which proves that Griffon benefits a lot from its Grails' heritage. Every Easyb story will have access to an app variable that points to the current app being tested, here is a trivial example
It will produce the following report

 1 scenario (including 0 pending) executed successfully

  Story: word finder

    scenario Hello WordFinder
      given a prefix string 'Hello '
      given a name is chosen, such as the application's title => WordFinder
      when both the prefix and name are concatenated into a greeting
      then the greeting should be equal to 'Hello WordFinder'

3. Code Coverage

What good can be tests without some metrics? fortunately for us the Cobertura project supports Groovy so we're able to rely on it to provide a code-coverage report. This is another plugin ported from Grails, the original one created by Mike Hugo of Piragua Consulting. Similarly to Grails, you'll get an additional script after installing this plugin (test-app-cobertura), but as an added benefit both FEST and Easyb plugins are able to piggyback on the code-coverage plugin (if installed) and provide you with a coverage report, just make sure to set a -cobertura flag when invoking run-fest or run-easyb. The following reports were obtained by running griffon run-fest -cobertura on the WordFinder application

As you can observe there are still a few kinks to figure out, for example the action closures on a controller still use the default name whereas the Grails' code-coverage plugin gives you the option to rename them to the appropriate value. Views can define a lot of closures, they should be filtered out from the report regardless of how many there are.

4. JDepend

JDepend is a very popular tool for determining the design quality of your Java software, it so happens to be Groovy friendly as well (after all Java is Groovy, Groovy is Java

). Once installed it will enable a new script, run-jdepend. When run, this script will inspect your code and create a report, like the one shown next

For this particular application, which is rather simple, there is nothing much to be shown as all the behavior is contained in the same package (the default one), only an external dependency on java.beans was detected. The plugin filters out all griffon related packages, as well as those automatically imported by the Groovy compiler, in the future you may be able to tweak the list of exclusions. Porting this plugin to Grails 1.1 is a simple matter, it can be done if there is enough interest so please let me know

We'll cover the remaining plugins on the next part.

Keep on Groovying!

Griffon plugins walktrough: testing

Posted by: Andres Almiray on March 27, 2009

1. FEST

2. Easyb

3. Code Coverage

4. JDepend

About Andres Almiray

Why Attend the NFJS Tour?

Current Topics: