Elegant Code » BDD

BDD Test Naming Experiment

David Starr — Mon, 08 Sep 2008 06:25:16 +0000

Of course, I am not the first person to do this, but gosh, isn’t it cool?

This is the test suite from a project I am working on and I decided to move the BDD naming convention into the syntax:
(class name) + (method name) = behavioral sentence

This library has 100% code coverage and tests the sad path pretty well, in my opinion.

Click the image to get a bigger view.

What’s your opinion? Is this easy to read to understand intent? Does this document my code for the next developer? Or is it just too much?

Indi Young on Mental Models

David Starr — Wed, 18 Jun 2008 01:19:10 +0000

I was fortunate to sit in a lecture today by Indi Young, co-founder of Adaptive Path and author of the recently published Mental Models, Aligning Design Strategy with Human Behavior. Ms. Young described her framework for constructing Mental Models, which are models representing a user’s thought process as they interact with a system. A Mental Model endeavors to give designers and application developers a usable way to see the system under development through the eyes of a user.

It is an interesting idea and an obvious compliment Domain Driven Design and Behavior Driven Design. The intent of the Mental Model is to allow designers to envision a user’s thought process and although it isn’t out-of-the-box simple, it is inherently useful.

She had some great feedback for our teams on creating more effective personas and user scenarios. Specifically, keep the personas behavior focused. For instance, I don’t need to know that Harold is a 38 year old fat guy, but I do need to know that he struggles to find content he is after on the web. Make sense?

At any rate, I have every good intention of reading her book and look forward to augmenting my toolbox with Mental Modeling.

Thanks to BDD

Alex Mueller — Thu, 01 May 2008 18:49:48 +0000

I have been doing code reviews frequently this past week and have been remarking on the naming conventions of test methods. In a effort to try and find the rules of BDD naming conventions, I came across Dan North’s introduction to BDD, which is a great starting point, and a blog post by David Laribee that has made a good impression on me. You can read up on BDD to learn more, this post will not go into detail about it.

From what I gathered from David Laribee’s article, I like this. I REALLY like this.

By changing namespace, class, and method names, the behavior of each spec (test) is clearly revealed. In a larger suite of tests, if there are failures, I can more easily see what is failing and what trends, if any, are resulting in my failures. Before, I would name my test method names to describe a behavior, "Some concept should do this when given that." Getting the namespace and class name involved provides a more legible test result.

While reviewing a test case for a peer, I took this approach and arrived at the following scenario. I am changing the names of the methods to hide details. The original test method was "FilterToEndPointTestReport." Making this more readable, using my previous approach, we arrived at "FilterShouldUpdateStatusOnReportWhenDefaultFilterValueIsChanged." Great, that is better, but…

Applying the approach described in David’s post, I now have this.

   1: namespace Specs_for_Filters   2: {   3:   public class When_default_filter_value_is_changed : FilterTestFixture   4:   {   5:     [Test]   6:     public void Endpoint_should_be_updated_on_report {}   7:        8:     [Test]   9:     public void Endpoint_should_be_updated_on_grid {}  10:       11:     [Test]  12:     public void Endpoint_should_be_updated_on_chart {}  13:   }  14:     15:   public abstract class FilterTestFixture  16:   {  17:     // provide common functionality that will be used   18:     // among behavior-driven filter test classes.  19:   }  20: }

When my tests run, their resulting output is more legible. This approach helps me to think about my tests in terms of behavior rather than implementation. In my opinion, my test cases are now more abstract and more succinct.