How to write integration and system tests in Asp.net MVC

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...

Hemphill

Problem is a bit unclear. There's not much to it what You already said. Mock out stuff You don't need for integration tests, do not mock at all for system tests. What kind of answers are You looking for? – Lactase

@Arnis L.: Unclear. You are probably right. I added some code to support my problem at hand. – Hemphill

At least the current version of the question is v. clear and a good question to ask, +1 – Nonflammable

@eglasius: You can still answer the question. It's not closed you know. :) – Hemphill

y, always intended to / just did :) – Nonflammable

Answer 1

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.

Vanburen

So you say that an integration test shouldn't use any mocks at all? I suppose that's called the "big-bang integration test" isn't it? But partial integration test should mock certain parts, shouldn't it? Do you do big-bang integration tests? – Hemphill

So you're basically saying that integration tests are non-mocked unit tests, while system tests are user interface process tests? – Hemphill

Based on these definitions: en.wikipedia.org/wiki/Integration_testing, I would say I tend to do sandwich testing, a combination of top-down/bottom-up, depending on what the component(s) or domains I'm testing. – Vanburen

I would say that mocking may be OK, but you want to ensure your application works with all of the resource it will utilize (as close as possible). If you are using a database, make sure your unit test has a database that it can use. Integration tests should not mock where you are testing the isolation of a single component; that's a unit test. An integration test should ensure that it's testing all of the components together, so be careful that if you do mock, you don't take away from that. – Vanburen

Answer 2

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.

Lexie

It is yes. Thank you. I'm asking a new question related to all your answers as well. Thanks. – Hemphill

Answer 3

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.

Nonflammable