I’ve been coding in the Behaviour Driven Development (BDD) style for a while now and thought I’d share my syntax at the state it has currently evolved to. Briefly, the idea behind of BDD is to have clear definition of business intent within your code, particularly your unit tests. The benefits are it’s easier to see what your system is supposed to be doing and your tests are more closely associated to the required behaviour of the system rather than the implementation, ergo, behaviour driven.
I originally started by making an effort to write my tests method names as sentences starting with “should” (e.g. should_set_active_status_to_false_when_status_updated), but having used the “Given, When, Then” format for our automated acceptance tests I’ve been trying to move more in this direction.
For a start, I’ve being using the Visual Studio solution explorer to help. Previously tests would be organised something like this:
Which I have replaced with this:
As you can see I’m using folders and file names to help give the tests context. One major advantage of this is as the tests are less coupled to the implementation of the system under test (SUT) any changes to the implementation are less likely to require moving tests around so the intent remains intact. The other obvious advantage is the intended behaviour is much clearer.
The next thing to show you is the tests:
The nice thing here is the namespace is taken from the folder and the class name from the file name so I’m getting a nice convention (even if it is being obfuscated by C# scaffolding). In this example I’m still sticking to the “should” convention but below I went for something a bit different:
So this is a little different because the conditions are more specific. There’s another class for non view direct users so I split them up, partly so the test method names needn’t be so long but mainly because it’s easier to understand what’s going on. Purists may feel uncomfortable with my relative lack of a standardised syntax, but the most important thing to me is it’s easy to see what’s going on and beyond that I don’t particularly care how you say it.
What this really is is a feeble attempt to mimic the elegance you get from RSpec (which we’ve been using along with Cucumber & Watir to write our automated tests). I was thinking today whilst I was playing with this that I don’t just want to mimic RSpec I actually want write my unit tests using RSpec. Excitingly it looks like the DLR and IronRuby will make this possible. Up until now I’d been struggling to think of a really appropriate use of a dynamic language within the .Net context but not any more.
February 5th, 2009 at 2:57 pm
Rob,
The real beauty of RSpec for unit testing is that it allows you to create subclasses of your TestFixture class that specialize the scenario you’re testing for.
I think this is possible with the xUnit frameworks, but it’s not easy. It’s a pattern I tried a few times with NUnit and felt pretty good, in some cases at least.
So for example in RSpec when you do this…
describe “a user”
before(:each) do
@user = TestFactory.create(:user)
end
describe “who is view direct” do
before(:each) do
@user.status = :view_direct
end
it “should immediately get access to previews” do
…
end
end
describe “who is view by request” do
end
end
…what you’re actually doing is creating a hierarchy of test classes on the fly, because #describe is a factory method for test cases.
I imagine you could replicate something like this C#, but it might be quite cumbersome to change.
February 20th, 2009 at 2:22 pm
I experimented with this kind of nesting in C#, using nested classes. A spec looks like this:
http://joshchisholm.com/svn/narrative/trunk/Narrative.Specs.Example/StackSpecs.cs
Grab the trunk of that project if you are interested.
February 22nd, 2009 at 5:20 pm
[...] a previous article I said I’d like to test my .Net code using RSpec so I’ve spent some time this weekend [...]