ATDD with MS-Test or NUnit

May 29, 2012

Normally ATDD and BDD are associated with special tools that allow non-developers like business people and testers write or at least read tests, without having to write code. Examples of such tools are FitNesse, M-Spec, SpecFlow, Cucumber and more.

However, even though these tools allow to specify tests scripts without code, often for business analysts these tools are too technical, or they just don’t have the mindset to specify tests in a well-structured “Given-When-Then” format.

About two years ago, the core group in Retalix tried to adopt ATDD using FitNesse, where the BA’s (Business Analysts) had to write the tests instead of writing specs, before handing them to the developers. Except for one team where the BA had very strong technical skills, all the rest abandoned the methodology and some even became eager objectors to it.

These days we start to re-adopt ATDD in Retalix, but in a different format: we’re separating the task of defining the scenarios (AKA examples or tests) from the task of writing them in a structured tool that can execute them. In addition, we’ve decided that it won’t be the responsibility of the BA to define all the relevant scenarios, but rather it will be a collaborative work of the BA, QA and developer. This collaboration helps nail down potential issues and misunderstandings early on. It also joins the strengths of all of the participants to yield more relevant scenarios, and a more polished specification. Usually, the BA brings the deeper business knowledge, the QA brings a more critic view, looking for edge cases, and the developer brings the more structured view that looks for similarities with other cases.

The Specification Workshop

This collaborative task of defining the scenarios that represent the desired feature to cover the user story is done in a special meeting, called a “Specification Workshop”*. In this meeting, which takes place once for each user story (or once per iteration for all user stories), the participants define the scenarios in collaboration and write them down as a free text Word document or email.

Developing the test in MS-Test

After the workshop, the developer starts implementing the tests in MS-Test using Visual Studio. Even though he writes the test in C# code, he must write it in the most readable way that reflects the scenario as close to the Word document as possible, hiding any implementation details in private methods. It’s the QA’s responsibility to make a code review to enforce this (even if the tester doesn’t know c#!). Only then is when the developer starts implementing the production code to make the test pass. Also, even though MS-Test (or NUnit to that matter) are mainly aimed at unit tests, these tests should be implemented at a higher scope, like integration tests.

* The term is “Specification Workshop” is taken from Gojko Adzic’s book “Bridging the Communication Gap”. ISBN: 978-0-9556836-1-9

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


one comment

  1. JudithJuly 28, 2012 ב 12:25

    The ATDD process has been a pireod of experimentation with the team. We’ve tried adding tests to acceptance criteria , to discussion posts, and as spreadsheets attached to the story. All the time we’ve been working on ways to measure its efficacy.ATDD has been intentionally lightweight to encourage quick and easy adoption.Our next step, which I think you’re asking about, is to use Rally’s quality control features: test plans, test cases, and test suites. IMO it is very important that this process does not impede regular work cadence. If we put too much process in the system it’ll become a moras of paperwork, questionnaires, and checklists. I’ve seen that happen and people just stop doing it.On the flip-side, if we can quantitatively demonstrate that any process overhead is worthwhile, enhancing quality, decreasing defect count, then it’s an easy sell and we’ll keep doing it.