Golf Tracker - Ep. 4 - Unit Testing

Golf Tracker - Repository Unit Testing

If you haven't heard, unit testing is very important to successful application development. 

Unit testing I consider to be an art.  Some people are experts at it, some are ignorant to it, and some like me, are just better than average at it.

Without going into too much detail about unit testing since this video doesn't cover what it is, I will say that the basic premise of unit testing is to create a test against your classes that have no dependency on anything physical such as a working database.  Everything that you test against should be either mocked or faked.  I'll talk about that in a second.

The primary thing you want to do in unit testing, is to create the smallest test you can on your classes, just to the point that it passes, and then move on to another test.

There are two primary thoughts for unit testing that you should follow:

• RED - make sure the first test fails.  You want to make sure that your tests can fail.  If you test passes without you doing much of anything, then something is wrong with your test.
• GREEN - make it pass.  Do what you can to make the test pass.
• REFACTOR - continue with more tests.  Once you make a test pass, move on and create another test.  If a previously Green test fails, this is most likely due to later refactoring to your application.  This is expected and it needs to be addressed.  There will be many times when you runs your tests that you will see many more failing tests than there should be.  When this happens, simply go back into those tests and do what is needed to make them pass.

The next thought is how you structure each of your tests.  Like mocking frameworks, and testing frameworks, there are different ways to handle this, but the way I'm going to demonstrate is the triple-A method.

• Arrange - arrange the code necessary to run each test.  This includes instantiating of classes, setting local variables, etc.
• Act - act on a method.  Once everything is arranged properly, you can execute a method call or something like that to get a result.
• Assert - assert the result is as expected.  Make sure that the result from the method call, is what is expected.

Initiating Tests

What I'll demonstrate here is how to create repository unit tests using fake data.

There are several ways to create unit tests, against mocks or against fakes.  Which one you use it entirely up to you but it will also depend on your skill set.  Mocking takes a bit more insight in a particular mocking framework (in which there are many) and a good knowledge of the framework you are working with that you want to mock.

Fakes on the other hand can be created fairly simply.  Fakes are generally classes that implement existing interfaces that actually contain fake data to emulate a working data source.  Many times I prefer working with fakes so I can test whether actual code is working and returning data the way I need.

In this set of tests I'll be faking the ICourseRepository interface and running tests against a few different methods.

I like to build a structure to my fakes that make it easy to refactor when necessary.  I generally build separate classes that contain some fake data, the concrete class that implements the interface and the unit test class.


In the image above, the CourseTests.cs file is the unit tests file, the FakeCourseData.cs file will contain fake data that emulates a data store such as SQL Server, and the FakeCourseRepository.cs file will implement the ICourseRepository interface.

Let me show you the FakeCourseData.cs code so you can see what I'm doing here.


The GetCourses() method returns an IQueryable<Course> and it creates 10 courses.  This will of course be embellished over time as needs arise but for now, it will suit our needs. 

Since I've chosen to have the primary keys as Guids, I need to hard code the Guids into the data instead of simply calling Guid.NewGuid().  By hard coding them, it allows me to call the GetByID(Guid id) method to return a single Course.  If the ID of the course was being generated by Guid.NewGuid(), it would be generating a random Guid every time and I would not be able to query against it.

The FakeCourseRepository looks like this.


Being a good programmer, I want to follow production-like procedures as much as possible and in this case I implement a pseudo-dependency injection into the class for the data.  This way I can swap out any data source that I want to test against.

In this example, at this moment, only the to GET methods are actually calling methods from the data source.  The Insert and Update methods are simply returning passed in data or creating data on the fly.  These can be embellished in the future as needed, but for now this is fine.

Here are some simple tests to get started.


These tests start out with some simple assertions.

• Assert the total records - get the number of records back and assert that the count is what is expected.
• Assert the returned type - get the Type that is being returned and make sure it is of the Course Type.
• Assert the course name - get a single Course and assert the CourseName value is what is expected.

There are several ways to run these tests.  You can either install the Visual Studio add-in from TestDriven.net which allows you to right-click inside the test methods and run each test, or install and the NUnit GUI.

If you install the NUnit GUI, it allows you to quickly see how all your tests are doing and which tests are failing if any.

When you open NUnit GUI, select File --> Open and locate your unit tests DLL file.  In this case, I'll select the GolfTracker.UnitTests.dll and click OK.  This is what you will see once the file loads.



You'll see that it loads all the methods of the assembly that you opened.  To run the tests, click the large "Run" button.  This is the result.



This of course assumes that all the test do pass.  If a tests fails, it will look like this.



It will tell you which test(s) failed and what the error message is on that test.  Apart from much more sophisticated testing frameworks, this is a simple way of creating unit tests for your application and then running all the tests and keeping an eye on which ones might fail.

This is especially helpful when you start refactoring your application.  By constantly checking your tests this way, you can see if any older tests break.  Refactoring always has the side affect of breaking some older code, and this is a great way of handling those situations.
Now that the unit tests are setup, we can add to them with tests that are needed for continuing development.

Stay tuned for more.