While I was researching a bit about BDD with the idea of implementing it in some project (or at least play a while with it), I stumbled with this (awesome) Machine Specification (or MSpec for short) framework which Rob Conery has explained in a great article you can find here.
The syntactic sugar looks really nice and it makes it very readable not only for developers but also for BAs. While this is probably a common practice for BDDeers and maybe for TDDeers too (I'm still learning, I must say) I liked also how Rob writes the specs as stories to then translate them to the code in a pretty straight-forward manner.
The html reporting and the MSpec runner are also kind of nice-to-have add-ons which make MSpec even more promising.
That said, the concern that rises -and which I've found when playing a bit with it- is: how does this adapt to low level requirements which do not have to do directly with a user-level story?
For instance, if I want to test that a DB connection is not left open, or that certain method in a given service is called, or that some property in a business class works as expected... Does BDD (or more specifically MSpec) adapt nicely to that kind of tests (or specs)?
In MSpec's syntaxis, it may seem a little bit verbose to write a new class, with a context just to specify that a given business object is created as expected, or that a DB connection is closed correctly.
But I think it is not an MSpec's "issue" (if we can call that an issue) but BDD's itself.
When testing low-level specifications as the one stated above, should we stay with the normal TDD implementation, without separating each scenario with its own context but just do the tests "class-oriented"?
Thoughts?
