I’ve been doing BDD with the ”context/specificationt”- style for about 4 months now. Examples for this style are MSpec, NSpec or my little framework called xUnit.BDDExtensions. What bothers me lately is that this style mixes context and behavior under test into one fixture class name, which can be extremely long because of that. An example to clarify what I mean:
“Adding a contact” is the observed behavior in the context of “no existing contacts”. I believe this should be more obvious, which made me thinking of how a syntax for this could look like. Having said that, here is what I came up with. It’s heavily inspired by MSpec and RBehave.
1 2 3 4 5 6 7 8
A generated report for this code might look like this:
Specifications for “PatientService”
- A patient with a missing first name is not allowed to be persisted
- Given a patient transfer object with a missing first name
- when trying to save the patient
- it should not persist the supplied patient
- it should return a report indicating that the patients first name is required
I’m still not 100% happy with this, because there is some sort of duplication between the fixture name and the “givens” (at least in the shown example), but with this approach you
- are able to separate context and behavior in a clean way,
- can describe the context very fine grained (by having multiple “givens”)
- and besides that it looks cool ;-)
I would like to hear opinions on that. Is this something worth implementing / adding to xUnit.BDDExtensions? Or am I off the track with this?