tednaleid / grails-test-data (http://grails.org/plugin/build-test-data)

Build Test Data plugin for grails. Decorates domain objects with "build" method that will inspect constraints and automatically create and save a valid domain object. Build method takes an optional map parameter that lets the caller set values. Authors: Ted Naleid and Joe Hoover

Welcome to the Build Test Data Grails Plugin

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?

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 constraints we've placed on our objects, and which objects depend on other objects to live.

Using this additional information, we've created a grails plugin that makes it easy to just provide those values that you want to exercise under test and not worry about the rest of the object graph that you need to create just to instantiate your domain objects.

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.

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 with all of the required constraints given values. 

def a = Author.build()

Plugin Objectives

  • The definition of the domain objects under test should be next to the test code, this improves test comprehension.
  • You should only need to create those fields and objects that are pertinent to the test. Other test setup is noise that obfuscates the meaning of the test.
  • Tests should not be dependent on other tests, only on the code under test. Therefore, the same test data should not be used by multiple tests, this creates a strong coupling and leads to test fragility.
  • Changes to domain objects that do not affect the the code under test should not break the test.

This revision is from 2010-01-08 23:51