Best practices of unit testing with OpenAccess

dbMockTest Write Up:

The goal of this sample program is show two very different yet useful ways of testing CRUD operations that rely on business logic. This type of scenario is very common in workflows where inserts, updates and deletes have constraints which are enforced by both requirements as well as foreign key constraints in SQL server.

This demo app includes the following:

1)      MDF file for sample database used in the application.

2)      Visual Studio 2012 solution with two projects (program and unit test).

Requirements:

1)      OpenAccess ORM (free to download via NuGet or available at Telerik.com)



 2)      NUnit (free to download via NuGet)



 3)      SQL Server 2012 LocalDB (free from Microsoft.com) or some other SQL Server. If another SQL server product is used, you will have to edit the connection strings. MDF file is include that can be attached to LocalDB through the management tools.



 4)      JustMock Free (available from Telerik.com)

What it does:

In the main project, Main in Program.cs carries out a very basic set of operations against a “live” SQL database. For the purposes of this demo, this is LocalDB with the include MDF file. This would simulate your production code.

In the UnitTest project however, two very distinct ways to go about performing unit tests on the production code have been implemented.

LocalDB Instance w/In Memory Changes

The first implementation (RealUserTestsUsingLocalDbChangesInMemory) leverages the .rlinq designer model file of OpenAccess which contains all of the relationships (foreign key constraints) to dynamically generate a new database in LocalDB that mimics the production database structure and relationships. Additionally, through dependency injection and by overriding SaveChanges() of the OpenAccess context for the DemoModel, the implementation was changed to call FlushChanges(). An interface is not created for the DemoModel due to the nature of the autogenerated code that is produced by OpenAccess anytime a change is made to the .rlinq file. This allows us to fully leverage the constraints of the production SQL server without ever committing those changes to the database and persist the CRUD operations in memory which allows us to receive autoinc identity values on inserts. At the end of the test run during the tear down, the dynamically generated database is destroyed. By leveraging [SetUp] and [TearDown], you can create a unique instance of the database for each individual test and by using [TestFixtureSetUp] and [TestFixtureTearDown], you are able to create a single database instance for a group of tests with the caveat that you will likely need to control the order with which the tests execute. Most would agree that this is a “smell” and should be avoided but it is useful to have the flexibility available to you.

Business Logic Tests Using JustMock

The next set of tests (MockUserTests) takes a very different approach. Instead of creating an environment that simulates the real world production environment and then cleaning up after itself, we instead mock out the various objects and even lambda expressions so that we can test purely the business logic and disconnect ourselves from any external dependencies.  We still make use of [SetUp] but for the mocking tests it only serves to create the mock of the database model and instantiate a business logic handler object (production code) that we will call to invoke the various inserts, updates and deletes.