Category Archives: TDD

by

Testing code coverage with NCover

I’ve been developing the recipe book website mostly using TDD (Test Driven Design) and I thought it would be interesting to measure the code coverage of my unit tests. After researching what tools were available it looked like NCover was the best fit for the sites technology stack. The commercial version has some good features, such as measures for cyclomatic complexity, however it is a bit out of my budget (of approximately £0!). Fortunately a community edition of NCover is also available for free and it stills works just fine for analysing current .NET assemblies.

After installing NCover a console application is available for running code coverage analysis. I got this up and running but the command line interface isn’t exactly the most user friendly and the output is just a single summary report. I obviously wasn’t alone in these conclusions because back in 2006 Grant Drake developed the NCoverExplorer tool to provide a GUI front end to NCover. This tool also has a community edition available (version 1.4) that works with the community edition of NCover.

Starters – Setting up NCover Explorer

The tool is fairly straight forward to setup, the NCover website includes instructions on how to setup the professional edition to profile an NUnit test project, and the settings are equivalent in the community edition. I also chose to specify which assemblies should be included in the coverage report as otherwise all the Sharp Architecture assemblies are included and the results are skewed.

After running the tool you are provided with an interactive view of the assemblies with the uncovered lines displayed in red. You can see how easy it is to identify the offending lines in the screen grab below:

The Main Course – Improving code coverage

The results of my first report are shown below:

The prime candidates for improvement were:

  • The RecipeBook.Data assembly. A couple of repository classes were not tested.
  • The RecipeBook.Web.Controllers assembly. Some of the code paths in the controller methods were not covered.
  • The RecipeBook.ApplicationServices assembly. Not tested at all, oops!

By default NCover sets the acceptable coverage level at 95%, however I felt that this was overly strict. I would rather spend the time writing fewer tests that I ensure are of a high quality than writing tests just to cover every single line of code. So I reduced the threshold to 80% and added tests to cover the essential missing features. Below if my much more healthy looking report.

For Desert – A report without the red sauce

OK maybe I’m stretching the food analogy a little too far with my headings now! By red sauce I mean those nasty red bars that were blazed across nearly every line of the report. Below you can see the report looks much more healthy after adding some unit tests and trimming some unused code:

I will endeavour to keep the coverage level at a minimum of 80% from now, and hopefully add some more tests to bump off those remaining pesky red bars!

As usual, any comments on this post are welcome. :)

by

Add recipe feature – task breakdown

The add recipe feature is the first feature that will added to the site. This task can first be broken down into 4 subtasks:

  1. Add a recipe summary
  2. List / add ingredients
  3. Add recipe ingredients
  4. Add a recipe cooking method

However, the sharp architecture framework is designed for Test Driven Development. These are the TDD steps listed in the sharp architecture reference guide (in the docs folder of the SVN project):

  1. Write your test as if the target objects and API already exists.
  2. Compile the solution and see it break.
  3. Write just enough code to get it to compile.
  4. Run the test and see if fail.
  5. Write just enough code to get it to pass.
  6. Run the test and see it pass!
  7. Refactor if necessary!

Taking another look at the feature subtasks from a TDD perspective, the breakdown for each domain object looks more like this:

Ingredient

  1. Add tests for the ingredient domain object and controller
  2. Implement the ingredients domain object and controller to make the tests pass
  3. Add Ingredients views for List and Create


Recipe

  1. Add tests for the recipe domain object and controller
  2. Implement the recipe domain object and controller to make the tests pass
  3. Add Recipe views for CreateSummary, CreateIngredients, CreateCookingMethod


Currently I just need to implement the Create view for the Ingredient object, then I can move onto recipes.

by

Setting up the NUnit GUI

I’ve setup the project using the default ‘S#arp architecture Application’ template. I won’t go into detail about the steps taken to do this as it is all covered in the Sharp Architecture documentation. However I did hit a snag setting up the NUnit project so I’ll expand on that in this post.

The Sharp Architecture template is setup for TDD (Test Driven Design) and this is the approach I will be taking to the development. Having installed TestDriven.Net, the tests can be run through visual studio, however I prefer the interface of the NUnit GUI. After each test run the results are displayed as a set of pleasing green ticks and/or nasty red crosses. Once you have a nice set of green ticks it becomes a bit of a fixation to keep it that way!

The unit tests for the visual studio project can be easily loaded into the NUnit GUI. All you need to do is go to File -> Open Project and navigate to the bin folder of the test project. Opening the compiled assembly (dll) of the test project will load all the unit tests into the GUI. Hitting the run button returns a nice list of green ticks as expected. However after saving the NUnit test project something alarming happens on the next test run. The standard Sharp Architecture Data tests all fail and nasty set of red ticks appear!

The following error message is reported:

SharpArch.Core.PreconditionException : Please add an AppSetting to your app.config for ‘nhibernate.mapping.assembly.’ This setting takes a comma delimited list of assemblies containing NHibernate mapping files. Including ‘.dll’ at the end of each is optional.

The error is pointing to a missing setting in the app.config file, however on checking the file the setting is present. Also the tests worked just fine before saving the NUnit project so why would they suddenly start to fail?

The cause of the test failures appears to have been saving the NUnit project, this pointed to some settings changes which NUnit may have made during the save. Taking a look at the NUnit project settings the possible cause of the problem became clear. There are a couple of directory and file paths in the settings, of particular interest are a ‘Configuration File Name’ and ‘ApplicationBase’ settings.

Configuration File Name
When the test project assembly is first loaded this setting has a value of RecipeBook.Tests.dll.config, however after saving the NUnit project the .dll part of the filename disappears. So NUnit is no longer able to find the config file and read the settings from it.

ApplicationBase
The ApplicationBase setting remains blank, however if you have saved the NUnit project in a different directory to the test project assembly you will need to change this. The path needs to be the relative path from your test project base to the test assembly location.

Below is an image of the settings for my project:


After updating these settings NUnit was able to read the settings for the config file and the GUI happily reported a lovely set of green ticks :)