测试数据库调用C＃

Question

First, let's address terminology here. Everything I search for says, "Unit tests don't touch the database!" I don't want a unit test. I want a test that when I send data to a database, I know that it correctly saves it (and testing of other crud operations). I have a repository layer that essentially accepts a DTO, then maps that DTO to an entity framework model, then saves that model to the database.

I need to be able to ensure that sending a DTO to these methods is in fact saving to the database.

An example method signature on the repository is:

public bool Save(SomeObjectDTO someObject)

I just need to test against whether or not this method call returns true.

What is the best way to set up tests where my methods being called are ones that save to the database?

Furthermore, is there a standard way to set up a blank testing database? It would be great if when I hit "Run tests" it constructs an empty database, fills it with initial data that is necessary, and then performs all the CRUD operations (all of my repository calls) to see that they all are saving like they should be.

I apologize if this is already answered, but everything I have searched either has someone saying you shouldn't be testing database calls, or people talking about mocking which is not really useful here.

I just want an example and/or the standard practice on how these types of tests should be set up.

Answer 1

What you're looking for is called integration testing, and is just as important as writing unit tests. There's a lot of potential bugs that are exposed by your underlying data provider that mocking your repository won't necessarily find (invalid foreign keys, null data for something marked as not null, etc).

I think it's also important that you test against the same database provider as your production system, otherwise there's a risk of missing implementation specific behavior. I use Azure SQL for a project, and instead of creating an in-memory SQL CE instance, I have a separate database on Azure that's only used for my integration tests.

If you use XUnit (and I'm sure it exists for other testing frameworks), there's a handy attribute [AutoRollback] that will automatically roll back your transaction after each test runs.

[Fact]
[AutoRollback]
public void AddProductTest_AddsProductAndRetrievesItFromTheDatabase()
{
    // connect to your test db
    YourDbContext dbContext = new YourDbContext("TestConnectionString")

    dbContext.Products.Add(new Product(...));

    // get the recently added product (or whatever your query is)
    var result = dbContext.Single();

    // assert everything saved correctly
    Assert.Equals(...);
}

After the test is finished, your database will be at a blank slate again (or whatever it was before you ran the test).

Answer 2

For testing against a database when using EntityFramework, here is how I roll:

First of all, I define the class that will access the ObjectContext with a factory for the ObjectContext if needed: in my case I work in a NT service, so the context doesn't live during a request, or some other scope: YMMV but if you are testing a component you could work in complete isolation without too much hassle since your factory for the context in the web would certainly fetch the context from the request: just don't initialize / close it in your DAL class.

public DataAccessClass: IWorkOnStuff
{
    public Func<DataEntities> DataAccessFactory { get; internal set; }

    private string ConnectionString;
    public PortailPatientManagerImplementation(string connectionString)
    {
        ConnectionString = connectionString;
        DataAccessFactory = () => { return new DataEntities(ConnectionString); };
    }

    /* interface methods */

    public IEnumerable<Stuff> GetTheStuff(SomeParameters params)
    {
        using (var context = DataAccessFactory())
        {
             return context.Stuff.Where(stuff => params.Match(stuff));
        }
    }
}

Now, what's interesting is that when you want to test this, you can use a library called Effort , which lets you map a database in memory. To do it, just create your class, and in the test setup tell Effort to take it from here:

public class TestDataAccessClass
{
    public DataAccessClass Target { get; set; }

    protected int Calls = 0;
    protected DataEntities DE;

    [SetUp]
    public void before_each_test()
    {
        Target = new DataAccessClass(string.Empty);
        Calls = 0;
        FullAccessCalls = 0;

        var fakeConnection = "metadata=res://*/bla.csdl|res://*/bla.ssdl|res://*/bla.msl;provider=System.Data.SqlClient";

        DE = Effort.ObjectContextFactory.CreateTransient<DataEntities>(fakeConnection);
        Target.DataAccessFactory = () => { Calls++; return DE; };

        SetupSomeTestData(DE);
    }

}

In the SetupSomeTestData just add the entities you want (references, etc) and now you can call your methods to ensure that your data do come from the ObjectContext as defined in your setup.

Funnily enough, just as mfanto notes, this is an integration test, not a unit test, but as he says it himself :

This does not sound like unit but integration testing for me!

You are right, I use the term "unit testing" in the title because of SEO reasons :) Also most people don't seem to know about the differences between them.

I don't know if this is the best way to test against an Entity Framework DAL; it took me some time to achieve this solution and I find it is not without merits, but I will be watching this question in order to see what other solutions are proposed.