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.