Create a basic spec

πŸ“˜

Are you using ReSharper?

If so, be sure to grab the ReSharper Templates! There's a template that will generate a stub of a spec for you.

Creating a spec is easy! First, import the SpecsFor, Should, and NUnit namespaces:

using System;
//using YourNamespaceHere;
using SpecsFor;
using NUnit.Framework;
using Should;

Next, decide class you are going to write tests for. This is your System Under Test (SUT). In your spec project, make a new class that has the same name as your SUT class suffixed with "Specs." If you're testing a class named Calculator, your specs would be named "CalculatorSpecs," like so:

public class CalculatorSpecs
	{
		
	}

Now decide what scenario or action you're going to test. This should be something you can describe in English, like "when adding two numbers" or "when validating an order." Create another class nested inside your spec class. Name this nested class after the scenario you are testing, like so:

public class CalculatorSpecs
	{
		public class when_adding_two_numbers
		{

		}
	}

Now make your nested class derive from SpecsFor. For the generic type parameter, specify your System Under Test. You should have something like this:

public class CalculatorSpecs
	{
		public class when_adding_two_numbers : SpecsFor<Calculator>
		{
			
		}
	}

Perfect! The base class will automatically create an instance of your SUT for you, and it will store it in a property named (you guessed it!) SUT.

Now you are ready to perform the action you are testing. The correct place to do this is in the When method, which you can hook in to by overriding it from the base class. If the scenario you are testing involves calling a method that returns data, capture the returned data in a field. Here's what our spec looks like now:

public class CalculatorSpecs
	{
		public class when_adding_two_numbers : SpecsFor<Calculator>
		{
			private int _result;

			protected override void When()
			{
				_result = SUT.Add(1, 2);
			}
		}
	}

Now you are ready to make sure the result matches your expectation. Think about what should be true after the action. In this case, the result should be three. Create a new method describing that scenario, and decorate it with the NUnit test attribute:

public class CalculatorSpecs
	{
		public class when_adding_two_numbers : SpecsFor<Calculator>
		{
			private int _result;

			protected override void When()
			{
				_result = SUT.Add(1, 2);
			}

			[Test]
			public void then_the_result_should_be_three()
			{
				
			}
		}
	}

Now implement the check within your test case. The Should library contains numerous assertions you can use.

public class CalculatorSpecs
	{
		public class when_adding_two_numbers : SpecsFor<Calculator>
		{
			private int _result;

			protected override void When()
			{
				_result = SUT.Add(1, 2);
			}

			[Test]
			public void then_the_result_should_be_three()
			{
				_result.ShouldEqual(3);
			}
		}
	}

Your spec is complete! Now you can execute it with your favorite test runner!

🚧

Wow there!

I bet you're thinking "that's a lot of code to assert one thing!" And you're right! SpecsFor is overkill for such a simple scenario. You can skip implementing the When method and write the entirety of this spec in a single test case if you want.

But for more complex scenarios, you will often want to assert multiple things. You do not want to assert multiple things in a single test case though, because only the first assertion to fail will be executed, and you won't be able to ascertain the result of the other assertions. With SpecsFor's When method, you can perform the scenario once, then put each thing you want to check in its own test case.