This plugin helps you to define a fixture, that is a defined set of data used for testing. The plugin defines a DSL in which you can express your need for data. Example:
fixture { guillaume(Author) { name = "Guillaume Laforge" } dierk(Author) { name = "Dierk Koenig" } gina(Book) { title = "Groovy In Action" authors = [guillaume, dierk] } }
Or a little shorter:
fixture { guillaume(Author, name: "Guillaume Laforge") dierk(Author, name: "Dierk Koenig") gina(Book, title: "Groovy In Action", authors: [guillaume, dierk]) }
Then, in your test case, you will want to load that fixture, like this:
class GinaTests extends GroovyTestCase { def fixtureLoader void testFinderMethod() { fixtureLoader.load("gina") def gina = Book.findByTitle("Groovy In Action") assertNotNull(gina) assertEquals(2, gina.authors.size()) } }
Pretty simple, isn’t it? Find out more about how to install and use the Fixtures plugin on its plugin page at grails.org.
Diese Artikel könnten Sie noch interessieren:
- Grails Paypal plugin 0.3 released The Grails plugins project has accepted me as a committer....
- “Prettify” your Grails app There are two nice small plug-ins for Grails that make...
- Grails Paypal Plugin V0.4 released Today, I released the Grails Paypal Plugin again, the new...
- Released OpenID plugin V0.2 for Grails Today, I released version 0.2 of the OpenID plugin for...
- Make your Grails app show content There is a great way to show content from inside...
Berater, Coach und Trainer für effektive Produktentwicklung
I see a problem in having fixtures stored under a directory where the test classes reference them. I don’t like the ability to share fixtures globally and I think it’s harmful like singletons. Tests should gather around a fixture, therefore the fixtures defined in the test class and the tests (aka test methods) reference them there. Otherwise, with globally shared fixtures you’d end up with a lot of not manageable dependencies. Heck, you are even allowed to have dependencies between the fixtures. What a dependency nightmare! Who could be able to maintain this?
So, if you won’t have the need for global fixtures, you could use inline fixtures. But then I don’t see the benefit of fixtures any more, since you could create the objects and store them in the regular way.
So what’s the point of having those fixtures anyway?
There could be one benefit: at the end of the test or at the beginning all created objects of those fixtures could be deleted from the database to ensure the test isolation. Then inline fixtures would make sense to me. But, sadly, there’s a note on the plugin-page: “The plugin currently does nothing special about tearing down the fixture data.” *sigh*
An alternative to fixtures that I think addresses Bernd’s concerns is the build-test-data plugin (disclaimer, I wrote it).
It allows you to easily create data inline with your tests and you only specify the fields that you need for your test and don’t need to specify any other extra fields that your test doesn’t care about.
One of the big wins of build-test-data is that it automatically changes as your domain changes, filling in all the required fields that you don’t specify for your test. This makes it much easier to change your domain without breaking a bunch of unrelated things.
Check it out as an alternative to fixtures for creating test data (or bootstrap data), I’ve used it on a number of projects
Cool – I’ll try build-test-data as an alternative!
Bernd,
I understand your concern about the fixture being a singleton. However, the main point why I found the plugin so attractive is the DSL for the definition of the test data. Maybe, it is possible to use the DSL and keep the fixture local.
This would be a nice enhancement for the plug-in. Plug-in writers, are you listening?
Matthias