My unit testing setup

In this second post of my series on unit testing, I want to run through the tools and packages I use.

There is a lot of choice! But this is my go to set up.

Resharper (test runner)

I have declared my love for resharper in previous posts, but I really like the test runner in there too. With a couple of keystrokes (CTRL+U, CTRL+L if you have the default resharper configuration to run all tests) it will run all my unit tests.

You can also run a single test from code by using ALT+ENTER, ALT+ENTER when on a test class name.

You can filter the test output to show just failed tests if you want, but I prefer to see all the tests have passed as well. Maybe it is just the pure satisfaction I glean from seeing lots of green ticks? It is a nice reminder that the code you are testing is a moving part in a bigger picture.

Another feature I love is that you can export the test results to text, XML or HTML. This means If you name you tests well, you can send this over to your business guys to verify you are testing the right things.

NUnit

There are lots of unit test frameworks out there, but I stick with NUnit. I for one, hate dogmatism. I'm sure this will become a theme throughout these posts. However, I have always found that I never need anything else above and beyond the functionality offered by NUnit.

It is also supported by the resharper test runner as well as all build servers I have used.

Fluent Assertions

Fluent Assertions is nothing more than syntactic sugar over the normal assert code. As the name suggests, it uses a fluent api over them. This means that your assertions read like plain english. For example:

public void FluentAssertionsSample()
{
	var someText = "Hello";
	Assert.AreEqual(someText.First(),'H');
}

Now that is a very simple assert, but with Fluent Assertions it would be:

public void FluentAssertionsSample()
{
	var someText = "Hello";
	someText.Should().StartWith("H");
}

I much prefer asserting from the variable in question, plus then it is so much easier to read. There are many methods you can use with fluent assertions, head on over to the documentation to see more.

You can add this to your project using the fluent assertions nuget package.

NSubstitute

With unit testing, you need to quite often mock dependencies. Don't worry there will be a future post on this...

When I started unit testing, I used moq. This served me well, until I discovered NSubstitute. I much prefer the fluent nature of NSubstitute. As an example, say you need to mock a dependency that returns the current date/time. If you don't do this, then your code isn't testable as I will discuss in a later post.

public interface ICalendar
{
	DateTime Now { get; }
}

public class CodeUnderTest
{
	private readonly ICalendar _calendar;

	public CodeUnderTest(ICalendar calendar)
	{
		_calendar = calendar;
	}
}

With Moq it would look like this:

[TestFixture]
public class FluentAssertionsTests
{
    [Test]
    public void MockingSample()
    {
        var now = new DateTime(2016,10,11);
        var calendar = new Mock();
        calendar.Setup(x => x.Now).Returns(now);
        
        var code = new CodeUnderTest(calendar.Object);

        //TODO: run the test method
    }
}

That will work, but with NSubstitute it will look like this:

[TestFixture]
public class FluentAssertionsTests
{
	[Test]
	public void MockingSample()
	{
		var now = new DateTime(2016,10,11);
		var calendar = Substitute.For();
		calendar.Now.Returns(now);
		
		var code = new CodeUnderTest(calendar);

		//TODO: run the test method
	}
}

I prefer the way it reads with NSubstitute. As well as the fact that you don't have to pass in '.Object' all the time like with Moq.

Again this is a simple example, but you can do the same with methods as we will see in future posts.

In this series:

  1. What is Unit Testing?
  2. My unit testing setup
  3. Remove statics to make code unit testable
  4. Allow me to mock your code