Christopher Bird

After writing my last post i’ve been thinking more about the question of “How should i organise my tests?”. The answer i gave last time seemed to work for fixing existing tests but didn’t seem to fix the cause of the problem that all the tests were still too much like unit tests. Oh yeah, at this point i’d like to point out i reserve the right to contradict myself.

While working on a separate RoR project I’ve used Cucumber to drive acceptance tests. If you’ve not tried it already, it’s great give it a go! Also on a side note i also discovered the guys who wrote selenium-client put a great deal more thought into the API than the .NET counterpart. Lots of extensions for waits and JQuery/Prototype integration are included by default. Anyway back to the problem at had, Cucumber forces you to write plain text stories (or features) and one or more scenarios for that story. Scenarios are written with each line start with “Given”, “When” and “Then” (and optionally And). Each line of the scenario corresponds to an executable “Step” that in my case performed a selenium action (or it could also quite easily perform an action against an API).

Anyway this method of writing test with the emphasis on the behaviour of the user (not surprising for a BDD tool) meant i ended up with less focus on one bit of functionality on a single page and more on the overall journey of the users actions through the application. Each scenario taking a different path or journey through that story.

Overall cucumber forced me to stay true to testing behaviour, avoiding the pitfalls of the test written in a plain unit testing framework. So, try cucumber, even if you don’t use it in your project i hope it makes you think differently about how you write the same tests in your native language.