After reading posts by Jean-Paul Boodhoo and Dave Laribee regarding BDD style naming conventions for specifications, my team gave it a shot on a project we started recently. It didn't take us long to agree that we preferred this naming style over the styles (or lack there-of) we had used in prior projects. We even found ourselves catching mistakes - in either the implementation or interpretation of the projects specifications - just by reading through the Dox report generated by the MbUnit GUI runner. We don't generally use the MbUnit GUI, however, and the output of the Dox report, though helpful, was not exactly what we were looking for. Since we have a continuous integration server running builds on every check-in, we decided to take a shot at having something generated during those builds. An example is seen below, which was generated using the MbUnit XML output from running the tests in the NothingButDotNetStore sample Jean-Paul has up on Google Code mixed with a custom XSL file.
We modified the build server's config to add a "specifications" report link when viewing the details of a build, and have definitely found it useful to have such an easy-to-read, always available and always up-to-date list of the specifications currently implemented by the project. While we're not quite to the point of being completely happy with what we've got - still some sorting, naming, organizational issues to work out - we definitely all agree that we are better off using this style of naming and having this report readily available for each build.
Here is a zip containing an MbUnit and NUnit version of the XSL we are using to generate reports like the one shown above. As I said, they really aren't perfect, but should get you started if you're trying out a similar style of naming convention. Let me know if you make any improvements.