How to write integration and system tests in Asp.n

Question

My application

I have an application design that looks like this:

• web application layer - asp.net MVC app with controllers and views that use POCOs and call services
• service layer - business processes that use POCOs and call repositories
• data layer - repositories that use POCOs and communicate with the model in the form of EF model which is part of this same layer
• POCO layer - defines all classes that are used for inter communication between these layers

So my data layer is completely transparent to data model implementation because upper layer don't use data entities at all.

Testing

As much as I understand unit, integration and system testing (with relation to Asp.net MVC) is this:

• unit testing - this one's easy. Mock decoupled objects and inject them in your unit test so tested unit will use them
• integration testing - should make a group of production functionality units and mock the rest: so writing integration tests that would test controller, service and repository integration without actually using production database
• system testing - run tests on all layers without any mocking, meaning I have to use production (test) database as well

Problem

I can easily see how to write unit tests as well as system tests, but I don't know how to write integration tests? Maybe my view of these is completely distorted and I don't understand them at all.

How should one write integration and system tests for an Asp.net MVC application?
Or any .net application for that matter?

Some code that helps explain the problem

Suppose I have classes like:

• TaskController calls into TaskService
• TaskService calls into TaskRepository
• TaskRepository manipulate EF data internally

So here are my (abbreviated) classes:

public class TaskController
{
    private ITaskService service;

    // injection constructor
    public TaskController(ITaskService service)
    {
        this.service = service;
    }

    // default constructor
    public TaskController() : this(new TaskService()) {}

    public ActionResult GetTasks()
    {
        return View(this.service.GetTasks());
    }
    ...
}

public class TaskService : ITaskService
{
    private ITaskRepository repository;

    // injection constructor
    public TaskService(ITaskRepository repository)
    {
        this.repository = repository;
    }

    // default constructor
    public TaskService() : this(new TaskRepository()) {}

    public IList<Task> GetTasks()
    {
        return this.repository.GetTasks();
    }
    ...
}

public class TaskRepository : ITaskRepository
{
    public IList<Task> GetTasks()
    {
        // code that gets tasks from EF and converts to Task POCOs
    }
    ...
}

Unit test is simple and would look like this:

public void UnitTest()
{
    var mock = new Mock<ITaskService>();
    // other code that mocks the service

    TaskController controller = new TaskController(mock.Object);

    // do the test
}

But when it comes to an integration test, how do I mock only certain parts of the integration.

public void IntegrationTest()
{
    // no mocking at all
    TaskController = new TaskController();
    // do some testing
}

First of all I can't just mock database here? I could mock repository and have real service and controller though...

Answer 1

Integration tests that don't involve the UI can still be written in NUnit, xUnit, etc.

For ASP.NET MVC in particular (or any web application), you can use WatiN or Selenium to write system/integration tests using the UI.

You might also want to look at T.S.T. for T-SQL unit testing, and SpecFlow if you are curious about BDD in .NET.

Note: I wrote this before the question was updated with code and a description of the specific situation. It doesn't really address the question anymore, but hopefully will still be interesting/useful to someone.

Answer 2

I just replied to a related question: Integration tests implementation. I think it addressed the issue here, by presenting a clear approach to take.

Part of the issue is that higher level integration tests get too complex v. quickly. Its the nature of the problem, so I prefer to make sure all the separate pieces work as intended, through unit tests and focused integration tests depending on the class involved.

With the above in place, you only need to make sure the separate pieces are hooked correctly, so I use the full system tests for that. This has the best of its effect if the code follows SOLID and DRY.

Answer 3

Integration tests should test the integration between components. While unit tests test individual pieces of a single component, integration tests the interactions between components, and are meant to work live. So an integration test would utilize a database and any other external dependencies, where its best to mock these services in unit testing.

System test to me would be functional testing (another level of testing using something like fit), or ui testing through a tool like testcomplete or telerik's QA tool.

HTH.