5 September 2008
Grails Testing Tip (DO’s, DONT’s and DOH’s): Fixture Data vs. Dependent Data
DO: Distinguish between Fixture Data and Dependent Data
Integration testing can be painful enough under the best of circumstances. Confusion around where data comes from, when it should be deleted, rolled back or committed can derail the even the best laid plans. (This is especially true in more complicated projects that involve multiple datasources, that are managed outside the GORM.)
To better manage testing, we (ALTERthought) classify the persistent data to be used in our integration tests into two categories: Fixture Data and Dependent Data …
Fixture Data is data that is pertinent to the test case in particular. Data is considered to be Fixture Data if the following core conditions are true:
- The data is represented by a Domain Object in your system
- The data is writable (create/update/delete)
Fixture Data should be provisioned in one of the following ways:
- Through a provisioning tool like DBUnit
- Explicitly in the TestCase setUp()
NOTE: The decision as to whether we provision data using a tool like DBUnit or ‘locally’ in the TestCase setUp() is largely based on the complexity of Domain relationships. The more complicated the Domain Object graph, the more likely we are to use DBUnit to set up the data relationships. This has proven particularly true on projects where we must integrate with legacy databases that are highly normalized, and/or we have multiple datasources. Test fixtures for simple data can easily be provisioned in the setUp() method.
Upon test case completion, any Fixture Data that was added to the system should be removed, leaving the database in a clean state (see The Clean Slate Principle), containing only Dependent Data. Data should be removed in one of the following ways:
- Through DBUnit processing
- In the TestCase tearDown()
- As part of the transactional TestCase rollback
NOTE: It is generally discouraged to explicitly remove the Dependent Data in the test method themselves! Unexpected test case errors can leave your DB in an unstable state with partially populated data.
Dependent Data is data that must be present in order for your test environment to simulate the real world, but is largely tangential to the test cases at hand. Ex: A code table containing the 50 US states, valid zip codes, etc.
Data is considered dependent data if all of the following conditions are true:
- The data is tangential to the test cases at hand
- The data in question is read only. Your test cases will never update or delete the data in question.
- The data can safely live in the DB between test cases.
Dependent data should be provisioned in SQL scripts that are run prior to any tests as part of the environment setup. Once it has been provisioned it need not be re-provisioned for every individual test case.
OK, that’s it! It may seem like obvious advice, but establishing a few simple rules can go a long way towards making testing of your next Grails app much less painful. Subsequent posts will talk a bit about using tools like dbunit to help achieve your testing goals, testing with multiple datasources, as well as advice/hints on testing the various components of a Grails app.
Technorati Tags: grails tests, integration testing, unit testing
This entry is part of a series on testing standards and advice that we (ALTERthought) have found useful as part of our Grails development initiatives.
