Using BDD style of tests

Question

Hi,

When using BDD for higher level of tests, then this language in tests - given,when,then seems easy to understand.I am using C#.So,what I do is name the class as "whenthishappens",setup is the "given",and then I have tests.But,how to use this style of BDD when writing tests for a class method.Or,should I have just tests named "shouldDoXXX".?

Answer 1

Hi there.

Here is a blog I wrote about BDD style tests for MSTest based code:

http://mrclyfar.blogspot.com/2010/02/amazing-mapping-demo-at-ted-2010.html. I used ideas from this blog post.

Personally I use StoryQ for my tests. StoryQ is a testing framework similar to MSpec and SpecFlow, in that you can write your tests out in a more descriptive manner. In the beginning, I did try using BDD naming for MSTest style code, but I found it to be less flexible then I wanted. I then experimented with MSpec, which is awesome.

In the end I chose StoryQ since it had that little bit more verbosity about it which I like. Makes it easier for me to write descriptive tests without having to use context inheritance.

Cheers. Jas.

Answer 2

Hi Jess,

I normally name my tests shouldDoXXXX where the test name describes what it should do for all similar contexts. So I might say shouldAddUpTwoNumbersCorrectly. This is a bit different to the way a lot of BDDers do it - the Ruby crowd particularly seem to like shouldAddTwoPlusTwoToMakeFour, so repeating the particular example they use. Whichever works for you!

Inside the test, I often write comments as Given / When / Then:

public void ShouldAddUpTwoNumbersCorrectly() 
{
    // Given two numbers
    // When I give them to the summer
    // Then the result should be the sum of the two numbers
}

Then I fill in the code between the comments. If the test is very simple I may skip the comments.

I don't bother with English-readable frameworks for a class test, because the audience is technical and capable of reading code. The BDD frameworks which do Given / When / Then were created largely to help with conversations with non-technical stakeholders, and to encourage developers to use their language. I don't find them useful at a class level. YMMV.