Forward: this has nothing to do with SharePoint :)
I’m using Entity Framework 4.1+ and the cool Code First capability on a current project. For those unaware, Entity Framework (EF) is an code representation of your database. Code First (CF) is an approach where you define classes & relationships between them and let EF do the work of creating the DB and data model.
Spare me the debate about “I can write the schema & queries better than EF”… that’s great… golf clap for you. Sure could and so could I, but I also wouldn’t be nearly as productive in creating this app I’m working on. So why do I use it over doing it all by hand? Well it is (1) a level of abstraction which in my case makes me (2) more productive in creating the application and (3) is easy to maintain going forward not to mention (4) I love some of the capabilities baked into EF’s CF model, specifically DB initializers, seeding the database & the testability.
One very cool aspect to EF CS is it is very friendly to writing tests. I’m not a huge fan of unit tests & much prefer integration tests… in other words: I’d much rather see my code working against a real database with real data than mocking everything up. CF helps you with this. First, when you create your model via code, you can pass in these database initializers ( see this blog post, jump to “Database Initializers” ) . In a nutshell, you can take one of these classes and pass it to the EF CF engine and it will populate with YOUR seed data, great sample data!
So I was having a problem with these initializers & my tests. My challenge was that when my tests would run, they would seem to overlap with each other and some would fail. However when I ran the failing tests independently, they passed. Further inspection yielded that one test’s work in the DB was affecting what other tests were doing. The obvious solution to this was to utilize transactions (specifically the TransactionScope ), but I was having trouble getting it to work as well as implementing it in my test projects. After a lot of searching I came up empty for an obvious answer but one response to a question did get me going in the right direction . Another challenge I had was that I wanted to use one set of DB initializers when for some tests (those that expected the DB to be empty) and another set for the DB to be seeded with sample data. I figured it would help if I posted the solution for others who search for the same stuff.
For reference, I use MSTest as my test framework, MOQ for mocking & the awesome Unit Test Runner tool window in Visual Studio that ships with DevExpress’ CodeRush .
The first thing I did was create a special class that would run once for all tests running under one test project. Creating a public static method decorated with the AssemblyInitialize attribute tells the MSTest framework to run this method once for each test run for the current assembly even if it includes multiple tests. I’m using this to force the creation of two databases: one that is seeded and one that is empty. After this runs I’ll have two databases that have the assembly in their name. Now my tests can be configured to use either database.
1: [TestClass]
2: public class TestRunDatabaseCreator {
3:
4: public const string DATABASE_NAME_TEMPLATE = “CPT_CDS_{0}”;
5:
6: [AssemblyInitialize]
7: public static void AssemblyInitialize(TestContext testContext) {
8: string projectName = GetCurrentProjectName();
9:
10: Console.Out.WriteLine(“Test assembly init: creating unseeded DB…”);
11: CreateUnSeededDb(projectName);
12:
13: Console.Out.WriteLine(“Test assembly init: creating seeded DB…”);
14: CreateSeededDb(projectName);
15: }
16:
17: private static void CreateUnSeededDb(string projectName) {
18: Database.SetInitializer(new SmokeTestCreateDbWithNoDataIfNotExists());
19: Database.SetInitializer(new SmokeTestDropCreateDbWithNoDataAlways());
20:
21: // create new DB connection to local SQL Server
22: string dbName = string.Format(DATABASE_NAME_TEMPLATE +"_UnSeeded", projectName);
23: string connectionString = string.Format(TestGlobals.CONNECTION_STRING_TEMPLATE, dbName);
24: var dbfactory = new DatabaseFactory(connectionString);
25:
26: // connect to DB to auto generate it
27: var customerContext = dbfactory.GetDataContext();
28: customerContext.Database.Initialize(true);
29: }
30:
31: private static void CreateSeededDb(string projectName) {
32: Database.SetInitializer(new SmokeTestCreateDbWithDataIfNotExists());
33: Database.SetInitializer(new SmokeTestDropCreateDbWithDataAlways());
34:
35: // create new DB connection to local SQL Server
36: string dbName = string.Format(DATABASE_NAME_TEMPLATE + “_Seeded”, projectName);
37: string connectionString = string.Format(TestGlobals.CONNECTION_STRING_TEMPLATE, dbName);
38: var dbfactory = new DatabaseFactory(connectionString);
39:
40: // connect to DB to auto generate it
41: var customerContext = dbfactory.GetDataContext();
42: customerContext.Database.Initialize(true);
43: }
44: }
Next, I wanted all tests to use these databases & ensure that any changes each test made were isolated to just that specific test. The easiest way to do this was to use a TransactionScope object which I stuck in the TestInitialize attribute. As long as I didn’t complete/commit the transaction, the changes would never be committed to the DB. Since all the tests would use the same thing, I created a base test fixture which I could use in all tests as you see:
1: public class BaseTestFixture {
2: private const string CONNECTION_STRING_TEMPLATE = “server=localhost;database={0};uid=sa;pwd=Password1!;”;
3:
4: private TransactionScope _transactionScope;
5:
6: // DB factory from Entity Framework Code First
7: protected DatabaseFactory Dbfactory;
8: // Code First entity context
9: protected CustomerCacheContext CustomerContext;
10:
11: public virtual string DatabaseName {
12: get { return string.Empty; }
13: }
14:
15: [TestInitialize]
16: public void TestInitialize() {
17: // block init from firing
18: Database.SetInitializer(null);
19:
20: // create new DB connection to local SQL Server
21: Dbfactory = new DatabaseFactory(GetConnectionString());
22:
23: // connect to DB to auto generate it
24: CustomerContext = Dbfactory.GetDataContext();
25:
26: // create transaction for everything in this testCreateStates
27: _transactionScope = new TransactionScope();
28: }
29:
30: [TestCleanup]
31: public void Cleanup() {
32: if (_transactionScope != null) {
33: _transactionScope.Dispose();
34: _transactionScope = null;
35: }
36:
37: CustomerContext.Dispose();
38: Dbfactory.Dispose();
39: }
40: }
Finally, I could create tests by inheriting the BaseTestFixture which not only created the EF CF context for me, but it also created the transaction scope for each test. There’s a virtual property (DatabaseName) which the test tells the base class which database to connect to, either the seeded or unseeded one.
1: [TestClass]
2: public class CustomerSmokeTests : BaseTestFixture {
3: public override string DatabaseName {
4: get {
5: string projectName = TestRunDatabaseCreator.GetCurrentProjectName();
6: string dbPrefixName = TestRunDatabaseCreator.DATABASE_NAME_TEMPLATE + “_Seeded”;
7:
8: return string.Format(dbPrefixName, projectName);
9: }
10: }
11:
12: [TestMethod]
14: public void TestGetCustomer() {
15: /// assign
16: CustomerContext.SaveChanges(); // trigger the initialization of DB
17: var customers = new CustomerRepository(CustomerContext);
18:
19: /// act
20: // get customer
21: var customer = customers.GetOne(c => c.PrimaryEmail == “ ken.sanchez@adventure-works.com ”);
22:
23: /// assert
24: Assert.IsNotNull(customer, “Failed to retrieve expected customer from DB.”);
25:
26: // verify data for customer
27: Assert.IsNotNull(customer.CrmData, “Failed to get CRM data for customer.”);
28: }
29: }
Hope this little trick helps someone else out there. You might ask why I didn’t use ordered tests… I find those to be a pain to maintain and once I found that special AssemblyInitialize attribute, I felt like this was exactly what I needed.