Droppin’ Pennies on context specs…

First off I want to make it clear that I’m not a guru on the topic, but I do find it interesting. The topic of course is Context Based Specifications. I’ve seen an emergence in interest in writing context based specifications lately on the blogosphere. However, everyone seems to be advertising it slightly differently…

One of the things that our team tries to aim for is to keep technical language out of our specifications. They should be human readable sentences, not “Yoda” speak. This is crucial if we want non technical people to actually read our specs to make sure the code is inline with what the business is attempting to do. The goal, in our humble opinions, is to work closer towards the ubiquitous language. The benefit is that documentation is updated along with the code, because it is the code.

Something that reads..

when_the_account_controller_is_given_valid_arguments_on_the_register_account_action

Doesn’t read as easy as:

when_registering_a_new_account

Another subtle change that our team made was to put the specs above establishing the context. In some cases it just seem to read better from top to bottom.

when_creating_a_new_account_for_a_user_with_a_valid_submission

– it_should_inform_the_user_that_the_account_was_created

– it_should_save_the_new_account_information

under_these_conditions

because_of

“It” being the system under test.

We don’t always get it right, but by trying to drop the technical language we force ourselves to step away and think about the problem that we are ultimately trying to address.

Again… this is just my our 2 cents.