I’ve made some enhancements to them in the interim that have made them even easier to use.

The most important alias is gtaf, which is short for “grails test-app” for failed tests.

It will search through your test output directory and look for any tests that failed. If it finds any, it will rerun only those tests. Otherwise, it will rerun all tests. That makes it easy to just use gtaf all the time. If any tests fail, it will open them up using Console.app.

If you’re not on OSX, or would like to use something else to view the failed test logs, just modify the testlog alias to do something different.

There are alternative versions of it to only run failed integration tests (gtaif – Grails Test App Integration Failed), failed unit tests (gtauf – Grails Test App Unit Failed) or attach a debugger to the tests as they run (gtadf – Grails Test App Debug Failed).

These aliases, plus most of the rest of my zsh setup, is available on bitbucket. If you haven’t used zsh before and are still using bash, I suggest switching over for the numerous benefits that it gives you.

Here’s the section of zshrc_general that has the grails testing aliases, just add this to your .zshrc/.bashrc and make sure to uncomment the appropriate GRAILS_TEST_LOG_DIRECTORY export if you’re not running grails 1.2 yet:

# grails > 1.2
export GRAILS_TEST_LOG_DIRECTORY=target/test-reports
 
# grails < 1.2
# export GRAILS_TEST_LOG_DIRECTORY=test/reports
 
# after grails-test if there were ERROR messages, you can open those logs with the Console.app using this
alias testlog='for F in `grep -lE "FAILED|Caused\ an\ ERROR" $GRAILS_TEST_LOG_DIRECTORY/plain/*.txt`; do echo ">>> opening" $F; open -a Console $F; done;'
 
# grails-debug-suspend doesn't exist by default, it's a copy of grails-debug with the suspend flag changed to "y" so that
# we can attach a remote debugger before it proceeds past startup
 
# aliases where you can optionally pass in a set of tests to run (or no argument to run all tests in that group)
alias gta=grailsTestApp
alias gtad=grailsTestAppDebug
alias gtau=grailsTestAppUnit
alias gtaud=grailsTestAppUnitDebug
alias gtai=grailsTestAppIntegration
alias gtaid=grailsTestAppIntegrationDebug
 
# aliases that will rerun any failed tests (or all tests if there aren't any failed tests)
alias gtaf=grailsTestAppFailed
alias gtadf=grailsTestAppDebugFailed
alias gtauf=grailsTestAppUnitFailed
alias gtaudf=grailsTestAppUnitDebugFailed
alias gtaif=grailsTestAppIntegrationFailed
alias gtaidf=grailsTestAppIntegrationDebugFailed
 
 
function grailsTestApp() { grailsTest grails "" $1 }
function grailsTestAppFailed() { grailsFailedTests grails "" }
 
function grailsTestAppDebug() { grailsTest grails-debug-suspend "" $1 }
function grailsTestAppDebugFailed() { grailsFailedTests grails-debug-suspend "" }
 
function grailsTestAppUnit() { grailsTest grails -unit $1 }
function grailsTestAppUnitFailed() { grailsFailedTests grails -unit }
 
function grailsTestAppUnitDebug() { grailsTest grails-debug-suspend -unit $1 }
function grailsTestAppUnitDebugFailed() { grailsFailedTests grails-debug-suspend -unit }
 
function grailsTestAppIntegration() { grailsTest grails -integration $1 }
function grailsTestAppIntegrationFailed() { grailsFailedTests grails -integration }
 
function grailsTestAppIntegrationDebug() { grailsTest grails-debug-suspend -integration $1 }
function grailsTestAppIntegrationDebugFailed() { grailsFailedTests grails-debug-suspend -integration }
 
function grailsFailedTests() {
	FAILED_TESTS=''
	for F in `grep -lE "FAILED|Caused\ an\ ERROR" $GRAILS_TEST_LOG_DIRECTORY/plain/*.txt`; do
		FAILED_TESTS="$FAILED_TESTS `echo $F | sed -E 's/.*TEST-(.*)Tests.txt/\1/g'`"
	done;
	echo "failed tests: $FAILED_TESTS"
	grailsTest $1 $2 $FAILED_TESTS
}
 
function grailsTest() {
	echo "Running: $1 test-app $2 $3 || testlog "
    time $1 test-app $2 $3 || testlog
}

I believe that they’ll also work fine as-is in bash, though I haven’t tested them.

Lots of good questions from the people in attendance. Thanks to everyone for showing up.

Here’s a version of it on slideshow:

I also released a new bugfix version of build-test-data earlier today (0.2.2). Mostly fixed bugs, but there’s also a new config setting that lets you disable the plugin in specified environments (suggested by Scott Vlaminck @ refactr.

So far, the proposals in the comments look fairly clunky to me and include defining whole sets of new methods like “assertEqualsButContinue(“foo”, “foo”)”, chaning assertions together jQuery-style, or using lists to hold all of our assertions.

Wouldn’t it be a lot nicer if we could continue to use the same methods that we’re already using?

In groovy, enabling soft assertions is easy with a little closure magic.

Closures have a property called the “resolveStrategy” that determines where the code inside the closure should look to resolve method names. The default resolve strategy is OWNER_FIRST.

Closure closure = { println "foo" }
assert closure.getResolveStrategy() == Closure.OWNER_FIRST

OWNER_FIRST means that if something isn’t defined inside the closure (local scope), it should check the owner of the closure to see if it can resolve it. The owner of the closure is the declaring class or another closure that contains our closure.

Closures also have a property called the “delegate”. By default, the delegate is equal to the owner, but we have the ability to change the delegate to something else. We can also change the resolveStrategy for the closure so when something isn’t defined, the delegate is the first place that is checked.

class Original {
   def closure = { return value() }   
 
   def value = { return "value from owner" }
}
 
class SomethingElse {
    def value = { return "value from delegate" }
}
 
def obj = new Original()
 
assert "value from owner" == obj.closure()
 
// the owner is the enclosing class, and its the same as the delegate by default
assert obj.closure.owner.class == Original
assert obj.closure.owner == obj.closure.delegate
 
// but we can change the closure's delegate to something else if we want
obj.closure.delegate = new SomethingElse()
 
// by default, the closure looks at the owner before the delegate, value is unchanged
assert "value from owner" == obj.closure() 
assert obj.closure.getResolveStrategy() == Closure.OWNER_FIRST
 
// changing the closure's resolve strategy switches who gets to handle value()
obj.closure.resolveStrategy = Closure.DELEGATE_FIRST
assert "value from delegate" == obj.closure()

Groovy also has a special metaClass method called invokeMethod that allows you to manipulate any method calls that are invoked on that metaClass.

Using these two things in conjunction, we can write a small class that lets us collect JUnit assertion errors thrown by any method starting with “assert”.

class SoftAsserts {
    def oldDelegate
    def failedAssertions = []
 
    static softAsserts(closure) {
        new SoftAsserts().bundleAsserts(closure)
    }
 
    private bundleAsserts = { closure ->
        closure.resolveStrategy = Closure.DELEGATE_ONLY
        oldDelegate = closure.delegate
        closure.delegate = this
        closure()   
        if (failedAssertions) {
            throw new Exception("${failedAssertions.size()} failed assertions found:\n${failedAssertions.message.join('\n')}")
        }
    }
 
    def invokeMethod(String name, args) {
        if (name.startsWith("assert")) {
            try {
                return oldDelegate.invokeMethod(name, args)
            } catch (junit.framework.AssertionFailedError e) {
                failedAssertions << e
            }
        } else {
            return oldDelegate.invokeMethod(name, args)         
        }
    }
}

This test class does a static import of the SoftAsserts.softAsserts closure so it can use it in a natural way.

import grails.test.*
import static SoftAsserts.softAsserts
 
class BookTests extends GroovyTestCase {
    void testBookTrueAssertsPasses() {
        def book = [title: "Infinite Jest"]
 
        // all 4 assertions pass and we are able to refer to local variables 
        // like book and local methods like trueMethod() 
        softAsserts { 
            assertTrue true
            assertTrue trueMethod()
            assertNotNull book
            assertEquals "Infinite Jest", book.title
        }
    }
 
    void testBookFalseAssertsCollectsFailures() {
        def book = [title: "Infinite Jest"]
 
        // all 4 assertions throw errors, but all are collected before 
        // an exception is actually thrown
        softAsserts { 
            assertTrue "False is not true", false
            assertTrue "falseMethod() is not true", falseMethod()
            assertNull "Book is not null", book
            assertEquals "House of Leaves", book.title
        }   
    }
 
    def trueMethod() { true }   
 
    def falseMethod() { false }
}

The first test shows how a passing test can successfully refer to other variables and methods defined inside the test class. The second test fails, but it doesn’t fail till all 4 of the assertions are tried and collected. It then throws an error with the assertion failure count and the individual error messages:

Testcase: testBookFalseAssertsCollectsFailures took 0.371 sec
	Caused an ERROR
4 failed assertions found:
False is not true
falseMethod() is not true
Book is not null
expected:<[House of Leaves]> but was:<[Infinite Jest]>

It might be useful to also print out the individual stack traces for each assertion error, but this is left as an exercise for the reader.

In most situations, I like the fail fast behavior and limiting tests to exercising one feature at a time, but there have been a few test cases where something like this would’ve been nice.

The build-test-data plugin makes creating integration test data easy. It decorates your domain objects with a “build” method that will create new domain instances and will automatically populate required fields with data and save it to the database. This enables you to create more maintainable tests where the data you create is targeted specifically at the situations you’re trying to test, without having to go through all of the ceremony of creating the rest of the object graph that you don’t care about.

// creates a new Book instance with all required fields 
// (like the Author that the book belongsTo) populated
def b = Book.build()

To learn more about the basics of the build-test-data plugin, see this blog post and check out the Basic Usage and Sample Code wiki pages.

To install, just run the install-plugin grails command (this will also upgrade an existing plugin):

grails install-plugin build-test-data

The 0.2 version of the plugin includes a number of enhancements and bugfixes. Major highlights include:

• JodaTime support (along with any other persistable class with a zero argument constructor)
• much easier and more powerful config files (see the TestDataConfig wiki page for details and examples)

Additionally, the code has been cleaned up and refactored to be easier to understand.

See the Release Notes wiki page for full details.

I’d be interested to hear any further feedback on this plugin and other features that people might find useful. I’ve successfully been using it on my current project and it’s been a big help in keeping my tests clean and free from superfluous object construction code, as well as flexible in that it automatically adapts to a changing domain model.

The aliases are primarily just the first letter of the words in the command, which makes them easy to remember (and saves on typing). Some examples:

gta                   # grails test-app
gtai                  # grails test-app -integration
gtaud AuthorService   # grails-debug-suspend test-app -unit AuthorService

My testing aliases are probably my most often used grails aliases. They’re all “gta” (for grails test-app) followed by an optional “u” or “i” (to run only unit or integration).

There’s also an alternate for each of those commands with a “d” on the end for “debug”. I call a script named “grails-debug-suspend” which is simply a copy of the normal “grails-debug” command, but with the “suspend” flag set to “y”. This causes the application to stop right away till you attach a remote debugger. This is very useful for quick tests as its often the case that the code gets past where you have breakpoints set before you launch the debugger.

These commands all also let you pass in the name of a specific test class so that only that test runs.

The overall format for all of the aliases is:

gta[i|u][d] [TestClassName]

This example suspends until a debugger is attached and then runs the AuthorServiceTests.groovy unit test class:

gtaud AuthorService

These aliases are all set up to run the “testlog” alias if a failing exit code is returned from the test run. This searches through all of the testlog results for any failures and automatically opens up each failing testlog in the OSX Console.app (if you’re on another platform, just substitute a different editor). I wrote a more detailed post a while ago about how nice Console.app is for looking at grails test logs.

Lastly, each command is also run with the unix “time” command, which I find useful to help me see how long my tests are taking and get a feel over time for the overall performance of the system under test.

# grails-debug-suspend doesn't exist by default, it's a copy of grails-debug with the suspend flag changed to "y" so that
# we can attach a remote debugger before it proceeds past startup
 
alias gta=grailsTestApp
function grailsTestApp() { grailsTest grails "" $1 }
 
alias gtad=grailsTestAppDebug
function grailsTestAppDebug() { grailsTest grails-debug-suspend "" $1 }
 
alias gtau=grailsTestAppUnit
function grailsTestAppUnit() { grailsTest grails -unit $1 }
 
alias gtaud=grailsTestAppUnitDebug
function grailsTestAppUnitDebug() { grailsTest grails-debug-suspend -unit $1 }
 
alias gtai=grailsTestAppIntegration
function grailsTestAppIntegration() { grailsTest grails -integration $1 }
 
alias gtaid=grailsTestAppIntegrationDebug
function grailsTestAppIntegrationDebug() { grailsTest grails-debug-suspend -integration $1 }
 
function grailsTest() {
	echo "Running: $1 test-app $2 $3 || testlog "
    time $1 test-app $2 $3 || testlog
}
 
# after grails test if there were ERROR messages, you can open those logs with the Console.app using this
alias testlog='for F in `grep -lE "FAILED|Caused\ an\ ERROR" test/reports/plain/*.txt`; do echo ">>> opening" $F; open -a Console $F; done;'

You can place these aliases in your .bashrc/.bash_profile in your home directory (you can also use them with cygwin on windows.

Alternatively, if you’re using zsh (or interested in switching from bash), I’ve got all of my zsh setup shared in a source control repo in a format that’s easy to use and extend for yourself.

This is the modified grails-debug command called grails-debug-suspend, just put it somewhere in your PATH and make it executable (chmod +x grails-debug-suspend):

#!/bin/bash
 
DIRNAME=$GRAILS_HOME/bin
. "$DIRNAME/startGrails"
 
JAVA_OPTS="$JAVA_OPTS -Xdebug -Xnoagent -Dgrails.full.stacktrace=true -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=5005"
startGrails org.codehaus.groovy.grails.cli.GrailsScriptRunner "$@"

Often an entire object graph needs to be created to support the instantiation of a single domain object. This leads to either the cutting and pasting of that creation code, or relying on a canned set of objects that we’ve grown over time and maintained as the domain objects change. After a while, adding just one more Widget to that set of canned data ends up breaking tests just about every time.

There has to be a better solution, right?

Yep! Due to the “Power and the Glory of Grails”™, we have a lot of metadata at our fingertips about those domain objects. We know what validation constraints we’ve placed on our objects, and which objects depend on other objects to live.

Using this additional information, Joe Hoover and I have created a grails plugin called “build-test-data”. With it, you can create test data and omit the fields that you don’t care about for your test. The plugin takes care of populating the values required by constraints and persists your domain objects to the database.

This plugin is focused on creating test data for integration testing. If you’re doing unit testing, there are a number of mocking solutions out there (including a few ways to do it built right into groovy). Unit testing only goes so far though, and if you want to ensure that your code works when it’s hooked up to a real database, with real transactions, saving, triggers, etc, you’re only going to get that from an integration test.

Installation of the plugin is easy. Just run this grails task in the root of your project:

grails install-plugin build-test-data

When the plugin is installed, most domain object should be able to be instantiated and persisted out of the box.

// automatically creates/saves a Book with all required fields populated
def book = Book.build()

Once installed, all you have to do is call the new build() method on your domain class and you’ll be given a valid instance that has been persisted to the database.

It will populate the required fields as defined by the constraints and it has the ability to deal with almost all of them.

A couple of them, such as custom validations and regular expressions, are very difficult to work with so if a sample value that we try doesn’t get past validation, we’ll throw an error.

Build Test Data Example

Here’s a quick example. Say you have the following domain objects:

// grails-app/domain/Author.groovy
class Author {
    String firstName
    String lastName
    static hasMany = [books: Book]    
}
 
// grails-app/domain/Book.groovy
class Book {
    String title
    Date published
    BigDecimal price
    static belongsTo = [author: Author]    
}

Remember that grails properties are required unless nullable is explicitly set to false, so all of those properties are required.

If you’re testing a BookPurchasingService and the method you’re calling needs a Book, normally you’d need to also create an Author to go with it. Here’s how you might normally create your test data without the build-test-data plugin:

void testPurchaseBookService() {
	def author = new Author(firstName: "first", lastName: "last")
	author.save()
	Book tenDollarBook = new Book(author: author, title: "title", published: new Date(), price: 10.00 as BigDecimal)
	tenDollarBook.save()
 
	def result = service.purchaseBook(tenDollarBook)
 
	//... assertions about expected result of service call
}

You need to create an Author just to create the Book, even though your service only cares about the Book. If the Author class ever adds an additional required field, you not only need to update all of your Author test classes, but all of your Book test classes as well.

Additionally, there’s all kinds of “noise” in your test class that makes it more difficult to understand exactly what it is you’re trying to test.

If you’ve got the build-test-data plugin installed, you don’t need to worry about any of that. Creating sample data is easy and you can specify only the parameters that you actually need specific values in to exercise your test. The plugin will fill in the rest and persist it to the database automatically.

void testPurchaseBookService() {
	def result = service.purchaseBook( Book.build(price: 10.00 as BigDecimal) )
 
	//... assertions about expected result of service call
}

Behind the scenes, build-test-data populates the Book.title and Book.purchased fields, it also creates a new Author with a firstName and lastName and saves all of that to the database.

This test is much cleaner as you only see the things that actually matter to the test and none of the administrative flotsam and jetsam needed to set things up.

In the repository on the bitbucket website, there is a test “bookstore” grails application that has a fairly complex domain model that exercises the build-test-data build method and it’s ability to serialize an object graph.

Check out the full set of documentation on the bitbucket build-test-data wiki and let Joe and I know what you think of it.

There are over 30 code samples in then article and I wanted to make sure while writing and editing that all of the code samples ran exactly as they appeared in the article text. Also, when you download an issue of GroovyMag, you get a zip file that has a PDF and a set of code “listing” files for each article. Each listing file contains a snippet of groovy code that appeared in the issue.

I decided to write a couple of simple groovy scripts to keep things DRY, and to ensure that my edits didn’t break anything. The first script extracts code listings out of my draft article and saved them to individually numbered listing files. The second script executes each of the listing files and reported success or failure for each. Sort of a poor man’s JUnit for writing articles.

Both of these scripts leverage regular expressions and the techniques that are outlined in GroovyMag.

I wrote the article using the markdown syntax. If you haven’t seen markdown before, it’s a wiki-like syntax that is very easy to read and write, and can also be converted into a variety of formats easily, including HTML.

In markdown, code blocks are simply lines that are separated from other lines by at least one blank line (or the start of the file) and are indented at least 4 spaces.

This is the script that I used to parse through the markdown file. It uses a regular expression to find all of the code blocks in the markdown and then writes each of them to it’s own listing file. Listing files were to be named consecutively from listing_1.txt through listing_n.txt.

#! /usr/bin/env groovy
INPUT_START_OR_BLANK_LINE = /(?:\A|\n\n)/
FOUR_SPACES_OR_TAB = /(?:[ ]{4}|\t)/
CODE = /.*\n+/
CODE_LINES = /(?:$FOUR_SPACES_OR_TAB$CODE)/
LOOKAHEAD_FOR_NON_CODE_LINE = /(?:(?=^[ ]{0,4}\S)|\Z)/
 
// this regular expression will find all of the consecutive code lines in a markdown file
// in a markdown file, if the line starts with a tab or at least 4 spaces, it's a code line
// slightly modified from one in markdownj
// see: http://github.com/myabc/markdownj/tree/master/src/java/com/petebevin/markdown/MarkdownProcessor.java
MARKDOWN_CODE_BLOCK = "(?m)" + 
                      "$INPUT_START_OR_BLANK_LINE" +
                      "($CODE_LINES+)" +
                      "$LOOKAHEAD_FOR_NON_CODE_LINE"
 
def removeOldListings(dir) {
    dir.eachFileMatch(~/.*listing_\d+\.txt/) { file ->
        println "Removing $file"
        file.delete()
    }   
}
 
 
def createListings(file) {
    listingNumber = 1
    (file.text =~ MARKDOWN_CODE_BLOCK).each { full, codeBlock ->
        def listing = new File("listing_${(listingNumber++).toString().padLeft(3,'0')}.txt") 
        println "Creating $listing"
 
        // groovy's String.eachLine skips blank lines, but we want these in our source 
        // to make things more readable so we'll make our own eachLine
        (codeBlock =~ /.*/).each { line ->          
            // each markdown code block comes back with a tab or 4 spaces at the beginning, strip those off
            def matcher = (line =~ /$FOUR_SPACES_OR_TAB(.*)/)
            if (matcher.matches()) {
                matcher.find { fullLine, code ->  listing << "$code" }
            } else {
                listing << "$line\n"
            }
        }
    }
}
 
removeOldListings(new File("."))
createListings(new File("article.markdown"))

Once I had all of those listing file, I used this script to execute each of the listing files and report whether any problems had occurred during the execution. It uses the “eachFileMatch” method groovy adds to the File object, which you can give a regular expression pattern so that you can iterate over a targeted subset of files to process.

#! /usr/bin/env groovy
def executeListings(listingDir) {
    listingDir.eachFileMatch(~/.*listing_\d+\.txt/) { listing ->
        print "Executing $listing..."       
        try {
            new GroovyShell().evaluate(listing)
            println "Success!"
        } catch (java.lang.AssertionError e) {
            println "ERROR!"
            e.printStackTrace()
        }
    }   
}
 
executeListings(new File("."))

Just like a good set of unit tests, these scripts gave me the courage to make edits to my article, without needing to worry if I was breaking something or forgetting to make a change. It’s a different kind of meta-programming when I can use regular expressions to help me write about using regular expressions :)

Some people, when confronted with a problem, think “I know, I’ll use regular expressions!”
Now they have two problems. — Jaime Zawinski

There is a common and well-earned aversion in the Java world to regular expressions. Prior to Java 1.4, regular expressions weren’t even part of the core language. Post 1.4, using regular expressions is still a painful task of working with Pattern and Matcher objects. Lots of typing is involved to make anything happen. It’s difficult enough that most Java devs don’t end up using them enough to actually remember how to read a regular expression, and they need to dig up the JavaDocs (or cut and paste an old example), every time they want to use them.

This aversion has persisted into the Groovy community to a level that I haven’t seen in other dynamic scripting languages like Ruby, Python, and (obviously) Perl.

The current regexp docs that pop up when doing a google search are all outdated and don’t use any of the best techniques that are available in the groovy 1.5.X and 1.6-beta code that is now available. The recent Groovy Recipes book doesn’t have an entry for regular expressions in the index, and I was unable to find a single example of a regular expression in the entire book.

This is unfortunate because Groovy makes using regular expressions much easier than in Java. Under the covers, you’re still working with the same old Java Pattern and Matcher objects, but the Groovy syntax and additions to those classes are pleasant to work with.

String Escaping with Slashy Strings

Groovy adds a new type of string escaping, Slashy Strings, that can be used to make your regular expressions easier to read. Forward slashes around text create String objects, just like quotes do. Unlike quoted strings, you don’t have to escape backslashes with another backslash in a Slashy String:

assert java.lang.String == /foo/.class
assert ( /Count is \d/ == "Count is \\d" )

You can also use groovy expressions Slashy Strings, just like double-quoted GStrings:

def name = "Ted Naleid"
assert ( /$name/ == "Ted Naleid" )
assert ( /$name/ == "$name" )

There isn’t anything specific to regular expressions with Slashy Strings, but many regular expressions use shorthand character classes such as \d (digit), \s (non-whitespace character), \b (word boundary) etc. The JavaDocs for Pattern actually has a nice reference for regular expression character classes if you’re not familiar with them.

Groovy Regular Expression Operators

Groovy adds 3 new operators

• “~” – used before a string and it will cause the string to be compiled to a Pattern for later use

// \b means word boundary, [A-Z] means any capital letter, + means one or more
// so this matches any string of one or more capital letter with a word boundary (non-word character) on either side of it
def shoutedWord = ~/\b[A-Z]+\b/

• “=~” – Creates a Matcher out of the String on the left hand side and the Pattern on the right.

def matcher = ("EUREKA" =~ shoutedWord)  
assert matcher.matches()         // TRUE
 
def numberMatcher = "1234" =~ /\d+/  
assert numberMatcher.matches()   // TRUE

• “==~” – Returns a boolean that specifies if the full String matches the Pattern

assert "1234" ==~ /\d+/    // TRUE
assert "FOO2" ==~ /\d+/    // FALSE!!!

Enhancements to the String Class

In Groovy, the String class has been enhanced with a few “replace*” methods that allow you to leverage regular expressions. These methods originally come from the Matcher class, but attaching them directly to String puts them right at your fingertips.

replaceFirst will replace the first substring matched by a regular expression within the specified String:

assert "Green Eggs and Spam" == "Spam Spam".replaceFirst(/Spam/, "Green Eggs and")

replaceAll will replace all matching substrings within the specified String:

assert "The armor was colored silver" == "The armour was coloured silver".replaceAll(/ou/, "o")

There is an alternate version of replaceAll that takes a closure for the second parameter. This is especially useful in the situations where you want to manipulate the matched value, or groups within the match to dynamically determine the replacement text.

For example, if we wanted to be able to turn a dashed phrase (“foo-bar”) into a camel case word (“fooBar”) we can’t just remove all dash characters, we also need to make the first letter after the dash capitalized (the “B” in “fooBar”).

To do this, we can use a regular expression that captures the first letter after a dash in a group using parenthesis.

 
def dashedToCamelCase(orig) {
	// regular expression is a dash, followed by parenthesis that form a group where we hold the word's first character
    orig.replaceAll(/-(\w)/) { fullMatch, firstCharacter -> firstCharacter.toUpperCase() }
}
 
assert "firstName" == dashedToCamelCase("first-name")
 
assert "oneTwoThreeFourFiveSixSevenEight" == dashedToCamelCase("one-two-three-four-five-six-seven-eight")

Using the version of replaceAll that takes a closure gives us a chance to manipulate the first character of the word and capitalize it. This closure is always passed the full matched text of the regular expression as the first value, and then any groups as subsequent values.

Here we modify a phone number and keep the area code group, but replace the exchange and station number with hash marks:

assert "612-###-####" == "612-555-1212".replaceAll(/(\d{3})-(\d{3})-(\d{4})/) { fullMatch, areaCode, exchange, stationNumber ->
    assert fullMatch == "612-555-1212" 
    assert areaCode == "612"
    assert exchange == "555"
    assert stationNumber == "1212"
    return "$areaCode-###-####"
}

Enhancements to Collections

Groovy also makes significant additions to what you can do with Collections. In addition to each, collect, inject, etc, there is a regular expression aware iterator called grep that will pass each item in the Collection through a filter and return a subset of items that match the filter. We can use a regular expression as a filter:

// regular expression says 0 or more characters (".*") followed by the string "bar" that is at the end of the string ("$")
assert ["foobar", "bazbar"] == ["foobar", "bazbar", "barquux"].grep(~/.*bar$/)

You can achieve the same thing with findAll but it takes a little more typing:

assert ["foobar", "bazbar"] == ["foobar", "bazbar", "barquux"].findAll { it ==~ /.*bar$/ }

Working with Matchers

As we’ve seen, using the =~ operator will return a Matcher object. Many of the existing regular expression examples on the web work by treating the Matcher as a list and getting the first (zero-based) element out of the list:

def matcher = "foobazaarquux" =~ "o(b.*r)q"
assert ["obazaarq", "bazaar"] == matcher[0]
assert "bazaar" == matcher[0][1] // get the first grouping of the first map

This is a little fragile as matcher[0] will throw an error if there was not actually a match. Calling matches() doesn’t help as matches only checks if the regular expression matches the WHOLE string:

("foobazaarquux" =~ "o(b.*r)q").matches()  // returns false!
("foobazaarquux" =~ ".*(b.*r).*").matches()  // returns true, ".*" matches 0 or more chars of any type

You can check getCount() to see how many matches there were for some safety:

def m = "foobar" =~ /quux/
if (m.getCount()) {
	// example won't get here as "quux" doesn't exist in "foobar", the count is 0
        println m[0]
}

A groovier way to work with Matchers leverages collection iterators and the built in closures that Groovy provides to them. Matcher supports the iterator() method and with that, gets everything else that any groovy List or Collection would have, including collect, inject, findAll, etc.

def paragraph = """
    Lorem ipsum dolor 12:30 AM sit amet, 
    consectetuer adipiscing 1:15 AM elit. 
    Nunc rutrum diam sagittis nisi 9:22 PM.
"""
 
def HOUR = /10|11|12|[0-9]/
def MINUTE = /[0-5][0-9]/
def AM_PM = /AM|PM/
def time = /($HOUR):($MINUTE) ($AM_PM)/
 
assert ["12:30 AM", "1:15 AM", "9:22 PM"] == (paragraph =~ time).collect { it }
 
assert ["12:30 AM", "1:15 AM"] == (paragraph =~ time).grep(~/.*AM$/)

A limitation of the iterator-based methods is that they don’t give you access to the individual groups (hour, minute, am/pm), just the full matched string (“12:30 AM”). The each method is more powerful because as it iterates through, it passes the full match as well as each of the individual groups into the closure.

("foo1 bar30 foo27 baz9 foo600" =~ /foo(\d+)/).each { match, digit -> println "+$digit" }
 
// result:
// +1
// +27
// +600

Another example (using the paragraph and time Matcher from above) showing how to pretty print all of the timestamps:

 
(paragraph =~ time).each {match, hour, minute, amPm -> 
    println "$hour:$minute ${amPm == 'AM' ? 'this morning' : 'this evening' }"
}
 
// result: 
// 12:30 this morning
// 1:15 this morning
// 9:22 this evening

Regular expressions are a powerful tool that Groovy makes as accessible as any other top-tier scripting language. Using techniques to break more complicated regular expressions into their component pieces can make them much more readable (as in the time example above).

If you’re doing any sort of string processing beyond a simple contains or split, regular expressions in groovy can turn mountains of Java into a couple of lines of code.

There are a number of libraries and techniques for unit testing with groovy. It comes with MockFor and StubFor out of the box, and you can also leverage Java libraries like EasyMock and Mockito if your needs aren’t satisfied by the built-in constructs.

The mock and stub implementations that I mention above work well for allowing you to control the behavior of any collaborators, but what if your method calls another method within the same class? None of those solutions (as far as I’m aware) allow you to replace the behavior of other methods on the Class Under Test (CUT). If you are trying to unit test your method in true isolation, you need the ability to stub out the behavior of internal methods on the class (for example, to throw an exception to test try/catch logic).

If you had the following CUT:

class ClassUnderTest {
    def testMe() {
        return "${first()}, ${second()}"
    }
    def first() {
        return "first"
    }
    def second() {
        return "second"
    }
}

If you’re trying to unit test the testMe method, you might want to control the values that come back from first and second to ensure that testMe still reacts as you expect.

This test helper class will allow you to test your methods in isolation, so you can focus on testing the logic in your Method Under Test (MUT), rather than worrying about the contortions that might be necessary to get helper methods into the state you want to test.

com.naleid.test.TestHelper.groovy:

package com.naleid.test
 
class TestHelper {
    public static def isolateMethod = { methodRef, stubMethods, closure ->
        def clazz = methodRef.owner.theClass
        clazz.metaClass.invokeMethod = { String name, args ->
            def stubMethod = stubMethods[name]
            if (methodRef.method == name || stubMethod?.owner == clazz) {
                // invoke a real method on the class , it's either the method we're testing in isolation or
                // one we've been told to pass through
                return clazz.metaClass.getMetaMethod(name, args).invoke(delegate, args)
            } else if (stubMethod) { // we have a stub method to use
                return stubMethods[name].call(args)
            } else {
                throw new Exception("Testing method in isolation; other method called that we haven't been provided a stub for: $name($args)")
            }
        }
 
        closure.call() // call the code that tests methodRef in isolation
 
        GroovySystem.metaClassRegistry.removeMetaClass(clazz) // clean up after ourselves
    }
}

What’s going on here? We’ve got a static method isolateMethod that allows us to pass in a method reference, a map of stub methods that we can control the behavior of, and a closure that will actually execute the tests while we have our method in isolation. We temporarily modify the metaClass of our CUT so that we intercept all calls to it’s instances. Then we execute the test closure that we were passed. Finally, we clean up after ourselves by reverting our CUT’s metaClass back to it’s original state.

There is some similarity here to the use keyword employed by MockFor and StubFor.

Well, it’s probably easier to show rather than just tell. Here is a GroovyTestCase that uses the static isolateMethod to change the behavior of first and second.

import com.naleid.test.TestHelper as TH
 
class IsolateMethodTests extends GroovyTestCase {
 
    def stubFirst = { return "stubFirst" }
    def stubSecond = { return "stubSecond" }
 
    void testIsolateMethod() {
        assertEquals("first, second", new ClassUnderTest().testMe()) // original behavior
 
        TH.isolateMethod(ClassUnderTest.metaClass.&testMe, [first: stubFirst, second: stubSecond]) {
            assertEquals("stubFirst, stubSecond",  new ClassUnderTest().testMe()) // stubbed out method behavior
        }
 
        assertEquals("first, second", new ClassUnderTest().testMe()) // back to original behavior
    }
}

We call the TestHelper’s isolateMethod and pass in the following items:

• ClassUnderTest.metaClass.&testMe – a reference to the testMe method that we get from ClassUnderTest’s metaClass
• [first: stubFirst, second: stubSecond] – a map of method names to stub closures that have replacement behavior for us to use

We also give it a closure that shows that we’re using stub methods rather than the real methods.

What if you still want the behavior of some of the sub-methods that testMe calls? All you have to do is pass in a reference to the real method and isolateMethod will pass it through.

void testIsolateMethodStubFirstRealSecond() {
    TH.isolateMethod(ClassUnderTest.metaClass.&testMe, [first: stubFirst, second: ClassUnderTest.&second]) {
        assertEquals("stubFirst, second", new ClassUnderTest().testMe())
    }
}

isolateMethod is also designed to throw an exception if a method that you haven’t given a stub is called by the MUT. Here is an example that shows what happens where we’ve given first, but neglected to include a stub for second:

void testIsolateMethodThrowsExceptionForMissingMethod() {
    TH.isolateMethod(ClassUnderTest.metaClass.&testMe, [first: stubFirst]) {
 
    def e = shouldFailWithCause(Exception) {
        new ClassUnderTest().testMe()
    }
    assertEquals("Testing method in isolation; other method called that we haven't been provided a stub for: second({})", e.toString())
    }
}

Using a technique like isolateMethod has the effect of making mocking libraries and unit testing much easier to work with, as you don’t need to worry about mocking out all of the collaborators that sub-methods of the MUT interact with.

I’m curious to hear how others have dealt with this issue in their unit testing in the past. Are there other solutions out there that I’ve missed?

One limitation that it does have is that the current testing scripts seem to be oriented more towards creating test reports rather than giving the user the quick feedback that is helpful when doing Test Driven Development.

Here’s an example of the output that you get on a failed test after running “grails test-app”:

-------------------------------------------------------
Running 1 Integration Test...
Running test BookTests...
testBookHasExpectedTitle...FAILURE
Integration Tests Completed in 622ms
-------------------------------------------------------
[junitreport] Transform time: 944ms
 
Tests failed: 0 errors, 1 failures, 0 compilation errors. View reports in /Users/ted/Documents/workspace/foobar/test/reports

Ok, that’s great…a test failed. But why? Where is the stacktrace and any output generated during the test?

As the output says, its down under test/reports. Once you get there, you see that there are a number of different output files and formats, everything from xml files, standard error/out files, as well as plain output files.

Even for the tests that pass, Grails still puts an output file in the reports directory for it. When you start to accumulate a number of different unit tests, it can be a pain to find the right output file and load it up in something that lets you quickly figure out the source of the problem in that long, groovy stacktrace.

Console.app and Aliases to the Rescue

OSX comes with a utility called Console.app that is normally used to look at system logs. It turns out that it’s also an excellent tool for looking at the output logs of Grails and for monitoring testing output when doing TDD.

OSX also allows you to launch any file (with the default file handler) from the command line with the “open” command. If you use the “-a” switch, you can pass it the name of an application

Combining that with a little grep magic and a for loop allows us to identify all of the test output logs that actually had an error or a failure:

alias oel='for F in `grep -lE "FAILED|ERROR" test/reports/plain/*.txt`; do echo ">>> opening $F with Console"; open -a Console.app $F; done;'

If you stick that in your .profile all you have to after running “grails test-app” is type “oel” and any failing tests will automatically pop open in Console.app.

Once the console is open, you can use cmd-K to clear the console and shift-cmd-R to reload it. The filtering abilities are also quite nice for finding relevant lines within the huge groovy stacktraces. Just type the name of your class or package in the filter box (opt-shift-F) and it will only show you the lines that match your filter.

Alternatively, I like to switch from filtering lines out to highlighting the filter text. This way, I can still see the surrounding stacktrace lines, but it’s easy to find the lines I actually care about.

My days of using tail and less are over, but if you’re on a non-OSX platform, you can easily substitute one of these commands in the alias that you execute (if you’re on Windows, check out cygwin).