Does ReSharper want to make your specs look like this?

But you want your specs to look like this?

Just follow these easy steps:

1. Go to Resharper>Options

   

2. Go to Languages>C#>Formatting Style>Other

   

3. Uncheck Modifiers>Use explicit private modifier

   

4. Uncheck Other>Indent anonymous method body and hit OK

   

5. Go to your project properties>Build and suppress warning 169

   

6. Enjoy!

Unlike vanilla TDD, the artifacts produced by BDD can and should be read by more than just developers. Most of us who practice TDD name our tests more or less like this:

MessageBoardControllerTests.Index_WithTenMessages_ReturnsFiveMostRecentFromRepository()

Shifting into Context/Specification style testing, one may be tempted to write specs like this:

MessageBoardController, when invoking index action when there are ten messages, 
  should return five most recent messages from the repository

The problem with this spec is subtle but important. You often want these specs to be readable and understandable by a normal person, someone in your business that can provide you feedback on your specs. Using words like "invoking", "index", "action" and "repository" are clear indicators that your audience is another developer. You should use the time writing specs to speak in the language of the business and to clarify your ubiquitous language. Here's how I'd rewrite this:

Message Board, when viewed
  should show only the five most recent messages

Again, the difference is subtle, but notice how I could show this to anyone in the company and they would understand exactly what is happening.

There are times for developer speak in specs I believe. If you are specing an API to be consumed by other developers I think it's ok to use words like "throw" and "return" because that is what the developers care about when integrating with an API.

Most of the time however, especially when writing the more UI/System Behavior level specs, you should consider who your audience is and try to speak like them. The code itself will provide the detail a developer needs to understand it.

As an aside, this is one of the many reasons I prefer the Context/Specification style to Given/When/Then style of BDD. Because people already don't speak in Given/When/Then prose in real life, it makes it even more difficult to write your specs for the intended audience. It also leads you to use magic numbers and other magic state in your prose rather than formalizing business concepts and improving your ubiquitous language.

It's been a while, but we've gotten several new things into Machine.Specifications (MSpec). I'm excited to finally release them for everyone to start playing with. You can grab the bits here.

Let's talk about what's new though. Here's an example of a new context/spec:

  [Concern("Console runner")]
  public class when_specifying_a_missing_assembly_on_the_command_line
  {
    Establish context = ()=>
    {
      console = new FakeConsole();
      program = new Program(console);
    };

    Because of = ()=>
      exitCode = program.Run(new string[] {missingAssemblyName});

    It should_output_an_error_message_with_the_name_of_the_missing_assembly = ()=>
      console.Lines.ShouldContain(string.Format(Resources.MissingAssemblyError, 
      missingAssemblyName));

    It should_return_the_Error_exit_code = ()=>
      exitCode.ShouldEqual(ExitCode.Error);

    const string missingAssemblyName = "Some.Missing.Assembly.dll";
    public static ExitCode exitCode;
    public static Program program;
    public static FakeConsole console;
  }

There have been a few semantic changes

• The Description attribute has been removed. There is now an optional Concern attribute that allows you to specify a type and/or a string that the context/spec is concerned with.
• Context before_each is now Establish context.
• Context before_all is now Establish context_once.
• Context after_each is now Cleanup after_each.
• Context after_all is now Cleanup after_each.
• When {...} is now Because of. This is closer to SpecUnit.NET's verbage, and doesn't force you to specify the "when" twice.

There is now a console runner

We don't quite have all the options we want yet, but the basics of the runner are working. Here's the help from the runner:

We also stole Bellware's SpecUnit.NET reporting stuff and ported it over. You can now generate a report on your specs with the --html switch. Here's an example run:

This is the report it generates.

Want to try it out?

1. Grab the drop here.
2. Extract it somewhere. Put it somewhere semi-permanent because the TestDriven.NET runner will need a static location for the MSpec TDNet Runner.
3. If you want TestDriven.NET support, run InstallTDNetRunner.bat
4. Check out the example in Machine.Specifications.Example. Note that you can run with TD.NET.
5. Create a project of your own. Just add Machine.Specifications.dll and get started.
6. Send me feedback! Leave comments, email me, tweet me, whatever.

Also, this is part of Machine, so feel free to take a look at the code and/or submit patches. There's also a Gallio adapter in there, but I didn't include it in the release as it's not quite polished enough yet. If you're interested in it, talk to me. Special thanks to Scott Bellware, Jeff Brown and Jamie Cansdale for their help and support. Also, extra special thanks to Eleutian's newest dev, Jeff Olson for much of the recent work that has gone into MSpec!

Mikel Lindsaar recently posted a tip encouraging rSpec users to not use before :each, and set up the context in every "it" specification.

I'm afraid I disagree. By pushing context setup into your specifications, you're allowing your contexts to become artificial and anemic and your specifications to become fat and more than just specifications.

Ultimately, this means that your reports will read poorly and it will be easy to introduce specifications in a context that do not match the others.

Mikel arrives at the following specs at the end of his post:

describe "when not logged in" do
  it "should redirect if we are not logged in" do
    get :index
    response.should redirect_to login_path
  end
end

describe "when logged in" do
  def given_a_logged_in_user
    session[:logged_in] = true
    session[:user_id] = 99
  end

  it "should let be a success" do
    given_a_logged_in_user
    get :index
    response.should be_success
  end

  it "should render the index template" do
    given_a_logged_in_user
    get :index
    response.should render_template('people/index')
  end
end