Todd Carter
Todd Carter

Reputation: 899

Using IOC To Configure Unit and Integration Tests

I have a unit test project which uses Ninject to mock the database repositories. I would like to use these same tests as integration tests and use Ninject to bind my real database repositories back into their respective implementations so as to test/stress the application into the DB.

Is there a way to do this with Visual Studio 2012 or is there another test framework, other than MSTest, which allows for this type of configuration?

I would really hate to rewrite/copy these unit tests into an integration test project but I suspect I could copy the files in as links and have a single test file compiled into two projects (Unit and Integration).

Thanks Todd

Upvotes: 0

Views: 384

Answers (2)

Low Flying Pelican
Low Flying Pelican

Reputation: 6054

With Nunit you can do this with TestCase,

say you need to use the unit and unit/integration test using CustomerRepository and OrderRepository,

[TestFixture]
public class TestCustomerRepository
{
    IKernel _unit;
    Ikernel _integration;

    [SetUp]
    public void Setup()
    {
       //setup both kernels
    }

    [TestCase("Unit")]
    [TestCase("Integration")]
    public void DoTest(String type)
    {
        var custRepo = GetRepo<ICustomerRepository>(type);
        var orderRepo = GetRepo<IOrderRepository>(type);
        //do the test here
    }

    protected T GetRepo<T>(String type)
    {
        if (type.Equals("Unit"))
        {
            return _unit.Get<T>();
        }
        return _integration.Get<T>();
    }
}

This is the basic idea.

Upvotes: 0

Steven
Steven

Reputation: 172676

Your requirements sound really odd to me. The difference between a unit test and an integration test is much bigger than just connecting to a database or not. An integration test either has a much bigger scope, or tests if components communicate correctly. When you write a unit test, the scope of such a unit is normally small (one class/component with all dependencies mocked out), which means there is no need for using a DI container.

Let me put it differently. When the tests are exactly the same, why are you interested to do the same test with and without the database. Just leave the database in and just test that. Besides these tests, you can add 'real' unit tests, that have a much smaller scope.

Upvotes: 1

Related Questions