Test Driven Development and FakeItEasy

Recently I've been working with Test Driven Development (TDD) and FakeItEasy. Test Driven Development is a test-first approach to developing software and FakeItEasy is a mocking framework. Using TDD and FakeItEasy together can help you build maintainable, loosely coupled solutions. Here are some of the key TDD principles:

Write a failing unit test first.
Write the minimum code needed to get the test to pass.
Refactor code to acceptable standards.
Use a mocking framework to test external dependencies.

Here are some of the benefits I’ve experienced recently using Test Driven Development and FakeItEasy:

Writing unit tests first helps drive the design of the project; it makes the solution more component based.
Mocking objects helps you build Interface based components that support dependency injection.
Test Driven Development helps you understand the requirements and the acceptance criteria for each use case/ user story.
Unit tests – with descriptive names – can provide valuable system documentation.

Here's an example of how to use FakeItEasy:

Step 1: Open Visual Studio. Add three class library projects to your solution:
-- DataService
-- Tests.IntegrationTests
-- Tests.UnitTests

Step 2: Right-click project “Tests.UnitTests”. Select “Manage NuGet Packages”:
-- Install-Package NUnit
-- Install-Package FakeItEasy
-- Add a new class called “When_calling_fake_data_service.cs”

Step 3: Add two unit tests to class When_calling_fake_data_service.cs. These tests won’t pass yet.
[Test]

public void Should_call_GetOrders()
{

// Arrange

var fakeDbClient = A.Fake<IDbClient>();

// Create system under test
var service = new DAL(fakeDbClient);

// Act
service.GetOrders();

// Assert

A.CallTo(() => fakeDbClient.GetOrders()).MustHaveHappened();
}

[Test]

public void Should_get_fake_orders()

{

// Create a fake expected response

  var expectedData = new List<Order>
  {
  new Order() {OrderId = 100, Description = "desc 100"},
  new Order() {OrderId = 200, Description = "desc 200"},
  new Order() {OrderId = 300, Description = "desc 300"}
  };

// Arrange
var fakeDbClient = A.Fake<IDbClient>();

// Tell FakeItEasy to return fake response when GetOrders is called

A.CallTo(() => fakeDbClient

.GetOrders())

.Returns(expectedData);

// Create system under test

var service = new DAL(fakeDbClient);

// Act
var result = service.GetOrders();

            // Assert
  Assert.AreEqual(expectedData, result, "Incorrect result from GetOrders!");
   }

Step 4: Select project “DataService”. Add the following code to class “DAL.cs”:
  public class Order
  {
  public int OrderId { get; set; }
  public string Description { get; set; }
  }

    public interface IDbClient
  {
  List<Order> GetOrders();
  }

    public class DAL
  {
  private readonly IDbClient _db;

        public DAL(IDbClient db)
  {
  _db = db;
  }

        public List<Order> GetOrders()
  {
  return _db.GetOrders();
  }
  }

    public class DbClient : IDbClient
  {
  public List<Order> GetOrders()
   {
  var lstOrders = new List<Order>
  {
  new Order() {OrderId = 1, Description = "desc 1"},
  new Order() {OrderId = 2, Description = "desc 2"},
  new Order() {OrderId = 3, Description = "desc 3"}
  };

            return lstOrders;
  }
  }

Step 5: Run both unit tests – they should pass now.

So what? What did we learn/ achieve?

FakeItEasy enables developers to test modules in isolation.
Creating interfaces is a best practice – it’s the first step towards mocking external systems.
Writing unit tests first helps developers to understand requirements and build component based systems.
Unit tests – with descriptive names – can provide valuable system documentation.

For more info check out:

http://pluralsight.com/ - Test First Development Part I & II

https://github.com/FakeItEasy/FakeItEasy/wiki

http://en.wikipedia.org/wiki/Test-driven_development

http://en.wikipedia.org/wiki/Unit_testing