Thanks to BDD
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.
Filed under: Uncategorized
I like the approach, and hey you might as well make better use of that namespace and class name… but I’m not sure I’d go back and change _just the names_ of existing test fixtures, only to meet readability or to satisfy a code review… seems like you’re merely “gilding the lily” at that point and not adding value.
Changing the namespace, or changing the class name, when I’m adding or editing a new test - well, maybe, because that’d take about a second. But altering all the test methods in name only?
I’ve been trying out different naming conventions for my tests lately, and often end up with ludicrously long test names. This looks like it might just be the solution to my woes
That’s really nice. Our team’s thinking about doing some specification work by unit-test-writing… I will give this a try. You’ll have to stop by and let Jay & I know how Office process somehow makes all of this not work.
That’s really nice. Our team’s thinking about doing some specification work by unit-test-writing… I will give this a try.
I agree, this is nice. Thanks, Alex.