Ted Naleid

A while ago I blogged about my grails testing aliases and how much time they save me.

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.
Read the rest of this article »

I gave a presentation tonight on the build-test-data grails plugin at the Groovy Users of Minnesota (GUM) meeting that was well received.

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

Here’s a version of it on slideshow: Read the rest of this article »

A recent blog post, Cedric Beust asks about how to cleanly implement “soft asserts”. Soft asserts are test assertions that don’t “fail fast”. Instead, all of the assertion failures in the test method are collected and reported at the end of the test.

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. Read the rest of this article »

I’ve just released version 0.2.1 of the build-test-data grails plugin.

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.
Read the rest of this article »

I’ve recently thrown together a few different command line aliases that have been very helpful in my grails development and I thought others might benefit from them.

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

Read the rest of this article »

Creating maintainable test data is hard.

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? Read the rest of this article »

The January 2009 issue of GroovyMag was released today. In it, I’ve written an article that shows how easy regular expressions are to use in groovy. It starts with some regular expression basics, shows some common idiomatic groovy usage patterns and wraps up with some of the cool new features that groovy 1.6 is adding to regexp handling.

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.

Read the rest of this article »

UPDATE: if you’re using Groovy 1.6.1 or greater (released April 2009), check out the new find and find all methods in this post.

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.
Read the rest of this article »

Glen Smith has been running a great series of posts this month to help people get started with unit testing. In that sprit, I thought I’d put out a post on some unit testing work that I’ve been doing recently.

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).

Read the rest of this article »

With Groovy built-in, Grails is one of the best platforms running on the JVM for doing unit testing.

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?

Read the rest of this article »