26 August 2008
Grails Testing Tip (DO’s, DONT’s and DOH’s): The Clean Slate Principle
DO: Follow the Clean Slate Principle
Its happened to all of us, a test that was working just fine, suddenly starts failing because the test database was left in an unstable state. Enter the Clean Slate Principle.
Grails integration tests should endeavor to follow a simple rule:
Leave the database in the state in which you found it.
In other words, if your tests perform any write operations on your datasource(s) (Create/Update/Delete) they are responsible for undoing said operation upon test completion.
This ‘Clean Slate Principle’ applies to Test Cases as a we as Test Methods within Test Cases… i.e., if a Test Method inserts a row into the DB as part of a test, it should be removed upon completion (regardless of success or failure).
Subsequent posts will discuss approaches for accomplishing this, as well as the types of pre-existing test data and techniques for provisioning. Until then, keep your slate clean!
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.
Technorati Tags: grails tests, integration testing, unit testing
6 Comments currently posted.
Edward says:
don says:
@Edward- Actually I have a couple of other posts in this series that talk about approaches for maintaining clean slate integrity between test runs (via setUp()/tearDown() methods, dbunit, and SQL scripts, etc…), but wanted to introduce the basic principle first as it is referenced in the subsequent posts. Thanks for the comment…
Mike says:
Actually – Grails test methods are wrapped in a transaction that rollsback when the test method completes – so your tests don’t really have to be responsible for cleaning up any data that they insert/update
don says:
@Mike – Yes this is the default case, however sometimes necessary to override this behavior for certain complicated scenarios (multiple datasources, etc) by setting boolean transactional = false in the test case.
Edward says:
@Mike – cool, but typically database transactions can’t roll back non-database updates such as external files, registry updates etc.
I still think it’s best for test suites to prepare their own test beds rather than assuming (or hoping as I put it) that the environment is ready and waiting for them.
@don – so I jumped the gun? :-) I often do…
ALTERthought Blogs » Grails Testing Tip (DO’s, DONT’s and DOH’s): Fixture Data vs. Dependent Data says:
[...] 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: [...]
Sure, tests should not trash the database, but this rule is perhaps a little optimistic? (Relying on the hope that nothing upsets the database between the completion of a test and the start of another, possibly an indeterminate period of time)
Practically speaking, a test suite should have a set-up function which prepares data before tests run, plus a test can check for prerequisites.
Sounds like your test didn’t check pre-requisites and had no associated set-up. Living in hope?