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..


Doesn’t read as easy as:


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.


- it_should_inform_the_user_that_the_account_was_created

- it_should_save_the_new_account_information



"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.

About Mo Khan

mO, is just a kid who's excited about writing software. He's a student of his profession, and just wants to share his thoughts on software development.
This entry was posted in TDD. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

4 Responses to Droppin’ Pennies on context specs…

  1. Groovy, I like the order.

    A concrete example that’s not completely trivial would I think be beneficial. Trying to break into BDD there just aren’t that many examples to draw from that aren’t completely synthetic.

  2. joey says:

    Hmm interesting putting the “establish context” below the specifications.

    So I understand the readability aspect of it and sharing the same language as the business user. But I believe you are forgetting the “other” user, “me”, the next developer that will maintain this codebase. If I am unaware of the Context/Specification style and just coming into your project, it seems out of order.

    - When given
    - it should
    - under these conditions
    - because of

    That doesn’t read well to me as the developer … think of the flow of tests it is going to run.

    - When given
    - Under these conditions
    - because of
    - it should

    It reads well for the business user and the flow of the tests as well for a maintenance developer.

    Remember, tests are supposed to be easy to understand! If I have to jump around the code to figure out the flow, that is a “test smell” to me.

  3. mO says:

    Thanks for the kind input. I’ll see what I can dig up for ya!

    Hmm… I’m not sure I get the “when given” syntax, but I think I understand what you’re trying to get at. For our team.. under these conditions IS establishing the context.

    So we read them as “when creating a new account for a user with a valid submission it should inform the user that the account was created”

    My experience with this style of testing so far has been that the “jump around” has decreased. Once you understand the context you read the “test” and should be able to immediately understand what is failing.

    Regardless of what team you jump into there’s always going to be time needed understanding that teams style of development. But you bring up some valid points, that I will definitely have to think over. Thanks for your input!

  4. Sean Kearon says:

    Mo, this is a simple and great idea and I love it! I use the syntax on the test classes already, but hadn’t thought of using it for the fixtures. When you do the test output reads just great!