More MSpec – ReSharper love
Visual Studio August 27th, 2010This is a follow up to the post about how ReSharper and Visual Studio messes with your MSpec specifications.
Resharper has built in support for naming inspections which is great for consistency if everyone in the team follows the same rules, but sometimes you just don’t want it. The most common scenario is when writing BDD specs (with tools like Machine.Specifications or MSpec for short).
This is a pretty common specification in our current project, and the class name might seem strange if you haven’t done BDD before. But the beauty of this is that the testing framework generates reports with this convention which is extremely readable for non-techincal people.
It will read something like this:
When an already handled customer is processed
– the customer should not be processed further
Or whatever you want to check. Our rake task always generates a html-page with all our specifications in a nice and readable format (more on that in a later post).
Well, back on topic! How do we tell Resharper not to scream WARNING, WARNING! at us all the time. We ARE naming things like this on purpose!
As everything always has been done by someone before, I’m only going to give you a link to the solution: http://www.aspiringcraftsman.com/2010/02/resharper-naming-style-for-machine-specifications/
You can add as many naming styles as you like to suit your specifications.
Happy mspeccing!
//J
PS. If you like the Visual Studio theme I’m using, go grab it from my repository over at github. Be sure to read the readme for the right fonts, otherwise the theme will hurt your eyes and probably your babies or kittens too.
August 27th, 2010 at 15:36
So, BDD, is it good?
August 27th, 2010 at 16:13
It sure suites us for the moment. It’s not the mother of all *** Driven Design, but it feels nice to have your applications behaviour in code but in (kind of) plain english.
That said, it shouldn’t substitute things like Unit Tests, but rather complement it. Our struggle right now is to distinguish what’s better suited for unit testing and what’s not.
August 27th, 2010 at 17:00
Interesting topic.
The purpose of the test case seems to be at a very high level. So I suppose the content of the test case should be at an appropriately (similarly) high level?
Implementation details don’t seem to go along with a test case at “user story” level, amirite?
(I’m not saying that the content of the test case in the blog is too low-level, but I suppose it could become an issue.)