This started off as a paragraph in a Grails for CFML Developers that morphed into an off-topic sermon.

In my experience, systems often start simple enough: an analyst says “these fields are nullable, these aren’t.” Six months into development, however, we start hitting oddball requirements like “Field Foo can be nullable after the setting of the seventh moon in the year of the cobra, or whenever the user ate tuna salad for lunch.”

After you add two or three of these that may or may not interact, testing the different permutations of a given form by filling it out manually and praying is just horrible: there are too many combinations of conditions to reliably test the new requirements, much less regression test earlier demands. Further, I’d much rather not spend any more of my life typing “asdf” into long forms to test a failing validation rule. Anytime I’m brought into an application and have to do so is a day I’ll be extra bitchy.

My experience has also been that once a system is released and “requirements gathering efforts” have ceased, people infrequently document that “Field Bar must be greater than the sum of fields Whee and Noony, except on alternating Tuesdays in even numbered non-leap years.” I’m sure we’ve all hit times when we’ve said “That’s not in any requirements document,” just to have someone eventually reply “Oh, that’s in the e-mail chain from last February, and we’re sorry you weren’t on it.”

When you write a test for validation, you’re creating a code-level specification of how the code should work. You can write a foo_is_nullable_when_seventh_cobra_moon_or_tuna_salad() test, or a bar_greater_when_not_tuesday_in_nonleap_even_years() test. Just looking at the names gives a more clear idea of how the code should work than most requirements documents I’ve read.

Enough Preaching, Why Test?

Tests shield us from all this malarky.

1. In the beginning, when life is simple, testing initial validation requirements gives a nice “Yep, we’ve done what we’re supposed to” translation of requirements into executable code.
2. When life gets more complex, tests let you validate multiple, complex rules and the effects of their interactions.
3. Once in production, when people trundle off into the world of e-mail instead of documentation, tests give you, the developer, an authoritative “source of truth” that specifies the current behavior of the model, regardless of e-mail chains and misinterpreted hallway conversations.