Monday 24 September 2012

Becoming a Father: One Year On – Part 4

This is the fourth part of my retrospective on my first year as a new father – though I’m starting to lag behind a bit now as my son is now nearly a year and a half old!

To view all the parts, please click on one of the links below:

  1. The Beginning
  2. The First Two Weeks
  3. Getting the Hang of Things

This post focuses on…

The Accident

Looking back now, the first six months of my son’s life were actually quite uneventful. I would hear stories of his little friends picking up bugs and colds but he seemed as healthy as you could hope, which is something to be thankful for. He never had so much as a sniffle. When he was around 7 months old though he would be paying a visit to the hospital.

One morning my wife was carrying him down the stairs when she lost her footing and slipped, sliding on her back down several of them. It left her a bit bruised and for an adult that would kind of be the end of it – just shrug it off, since it wasn’t that serious – but my son was crying uncontrollably. We couldn’t figure out why as we checked him all over and couldn’t see any marks or bruises anywhere, but he simply wasn’t himself. Our initial thought was that the incident was too much of a shock for him, but after about an hour our instincts told us to get him checked out. As this was a Sunday calling the doctor was out of the question, so a trip to A&E it was.

After waiting for hours that afternoon we had several doctors check him out and the overall conclusion was that he was just in shock still. We did consider maybe a broken bone but pressing on any part of him seemed to illicit crying so no-one could tell. In the end we took him home and gave him Calpol to help him sleep through the night.

The next morning while I was at work my wife texted me to say she was taking him to our GP to get him seen again as he still wasn’t right, who then referred him back to the hospital to get an X-ray on his right leg. Around 4pm I got a call saying that he had a hairline fracture on his right femur and would need to be put in traction, which meant of course staying in the hospital. And that was the start of the week-long “holiday” on the children’s ward.

I left work early to run home and pick up a few overnight things for my wife and son and went straight to the hospital to see them. He was on baby morphine to help him with the pain and still was not himself. My wife was now constantly blaming herself for a) inflicting this on him, even though it was an accident that she could not have prevented, and b) not spotting his broken bone sooner, despite not having X-ray vision herself.

I watched him as the nurses put him in traction, basically by lying him in bed and wrapping bandages and splints around both legs then tying them to pulleys hanging above his bed; the aim was to keep the leg straight so that it would heal faster – there is no magic cure for broken bones, you simply have to let your body heal itself. Fortunately it was only a hairline fracture and, given his age and constant body development, he would heal a lot faster than an adult (he was well on the mend in a week, whereas it might take me months to heal the same wound).

I stayed with them for a few hours before leaving them for the night; my wife would be staying with him around the clock whilst I would still have to go to work each day. That night was actually the first time ever that I was separated from my son; as I walked past his bedroom at home that night I looked into it and it was empty for the first time, which made me feel more alone that I expected.

The Sleepover

So far it is all sounding doom and gloom, isn’t it? Well let me reassure you by showing you what my son looked like for the rest of the week.

As you can see after his first night in hospital he was pretty happy with life. And wouldn’t you be when you have toys surrounding you in your bed and CBeebies on tap? If anything it was harder on my wife, which I will get to.

As I still had to do my day job I was responsible for ferrying items to and from home for them and visiting them first thing in the morning before work and straight after work before going home. I would then get the luxury of sleeping at home, ready to start the routine all over again.

My wife on the other hand stayed with our son 24/7. He got a room on the ward meaning my wife could sleep on a sofa-bed with him. For five days in a row she lived on the ward with him. By the fourth day she was almost at breaking point and when the weekend finally came so I could take over she vomited on the way home through sheer exhaustion. When I did my weekend shift straight after work on the Friday night I could finally understand what it was like; the ward was never truly quiet, always having staff roaming around and coming in to do observations on my son, day and night. There was even another child on the ward who sounded a lot worse than our son; I would periodically hear uncontrollable screaming from down the corridor, so I don’t know how that child’s parents managed to survive.

But we did it for him because as parents that is simply our job; to put him before ourselves. And he seemed to be having a whale of a time, getting visits from his grandparents regularly and only getting bored now and again. Let’s face it, he could have been a lot worse.

Coming Home

After just over a week (and my wife having a weekend of sleeping at home while I took over) he finally got discharged. He was also getting sores from the bandages on his legs so had to come out of traction anyway but his leg had almost healed completely, we just needed to be careful how we positioned it and keep him on his back. My wife took him for check-up X-rays and a month later he was given the all clear.

In fact now we forget that it ever happened. He is so active and runs around all over the place that it is hard to imagine that his leg was ever broken; people even now ask us how his leg is and we have to think for a second as to what they mean.

Plus, as the doctor at the hospital pointed out to me, it is safe to assume that this will be the first of many accidents he may experience in his lifetime as kids will always get into scrapes in their continual quest to have fun.

Next time: One Year Old…

Friday 14 September 2012

Testing Framework Review: xUnit.net

In a previous post I reviewed NUnit. For my last post in this series I will focus on xUnit.net. xUnit.net is a newer open source framework that is gaining some traction. From the xUnit.net website on CodePlex:

xUnit.net is a unit testing tool for the .NET Framework. Written by the original inventor of NUnit, xUnit.net is the latest technology for unit testing C#, F#, VB.NET and other .NET languages. Works with ReSharper, CodeRush, and TestDriven.NET.

xUnit.net is a developer testing framework, built to support Test Driven Development, with a design goal of extreme simplicity and alignment with framework features. It is compatible with .NET Framework 2.0 and later, and offers several runners: console, GUI, MSBuild, and Visual Studio integration via TestDriven.net, CodeRush Test Runner and Resharper. It also offers test project integration for ASP.NET MVC.

xUnit.net is even used internally by some high profile Microsoft projects such as:

Integration

xUnit.net is a separate project meaning that direct Visual Studio integration support is not provided. However Visual Studio 2012 will allow different frameworks apart from MSTest to be used as the primary unit testing framework – this includes TFS builds too.

In the meantime, the following steps are required:

Download from NuGet

NuGet provides three packages for xUnit.net:

Adding these packages to a Visual Studio project is very simple as NuGet will automatically download the latest versions and insert the correct project references required.

Project Items and Snippets

Unlike MSTest which provides project items and snippets with the IDE, xUnit.net does not provide any by default. However these items are not difficult to create yourself if required and the CodePlex project page even explains how to create snippets for xUnit.net.

Standalone

Although some initial setup is required one possible benefit is that xUnit.net is a standalone framework – it can be run anywhere without requiring installation, simply by copying the correct files.

Team Build

TFS 2012 will be able to use the same Unit Test plugin model that Visual Studio 2012 uses meaning in the future it will be a lot easier to integrate xUnit.net into the Team Build process.

Until then though it is possible to use xUnit.net within Team Build but only via a custom build activity and translating the xUnit.net XML output into MSTest results. This webpage explains how it is possible to do it, though the process looks quite longwinded to me.

Writing Tests

Tests are written like this in xUnit.net:

   1: using System;
   2: using System.Collections.Generic;
   3: using System.Linq;
   4: using System.Text;
   5: using Xunit;
   6: using Xunit.Extensions;
   7:  
   8: namespace SampleCode.xUnit
   9: {
  10:     // Classes do not require attributes, xUnit.net does not care
  11:     public class CalculatorTests
  12:     {
  13:         // A "fact" is a test without any parameters    
  14:         [Fact]
  15:         public void Add_AddOneAndTwo_ReturnsThree()
  16:         {
  17:             var result = Calculator.Add(1, 2);
  18:  
  19:             // Many asserts are provided by default, API style is simple and concise
  20:             Assert.Equal(3, result);
  21:         }
  22:     }
  23: }

There are a much wider variety of assertions provided by xUnit.net by default compared to MSTest. A full list can be found here.


Data Driven Tests


Data driven tests in xUnit.net are known as theories. They are test methods that have parameters and can accept input from a number of sources. A theory looks like this:




   1: [Theory]
   2: [InlineData(1, 2, 3)]
   3: [InlineData(3, 4, 7)]
   4: [InlineData(30, 10, 40)]
   5: public void Add_AddDataValues_ReturnsExpectedResult(int first, int second, int expected)
   6: {
   7:     var actualResult = Calculator.Add(first, second);
   8:  
   9:     Assert.Equal(expected, actualResult);
  10: }

Out of the box xUnit.net can accept input from the following sources:



  • Inline data
  • Property data
  • Excel spreadsheet
  • OleDb connection
  • SQL Server database

Running Tests


Until Visual Studio 2012 comes out xUnit.net tests cannot be run directly via the IDE but there are a number of other options available.



The console runner is the most basic test runner available and works from the command line.



The GUI runner is a simple standalone application with it’s own user interface and is not as full featured as the NUnit GUI runner but is capable enough. Instead of a tree view like the NUnit GUI runner this test runner presents a flat list of tests but they can be filtered down by search terms, assembly and/or trait values.


One aspect that is different from the NUnit GUI runner is that although this runner will detect and reload test assemblies when rebuilt it will not automatically run the selected tests again, unlike NUnit.


MSBuild


Unlike MSTest and NUnit, xUnit.net provides it’s own custom MSBuild task which allows direct integration into the build process. A project file can then use it similar to this:




   1: <UsingTask 
   2:     AssemblyFile="..\packages\xunit.1.9.1\lib\net20\xunit.runner.msbuild.dll" 
   3:     TaskName="Xunit.Runner.MSBuild.xunit" />
   4: <Target Name="AfterBuild">
   5:     <xunit Assembly="$(TargetPath)" />
   6: </Target>

Build output then looks similar to the following:


------ Build started: Project: SampleCode, Configuration: Debug Any CPU ------
SampleCode -> C:\TalentQ\Experiments\UnitTestAnalysis\SampleCode\bin\Debug\SampleCode.dll
------ Build started: Project: SampleCode.xUnit, Configuration: Debug Any CPU ------
SampleCode.xUnit -> C:\TalentQ\Experiments\UnitTestAnalysis\SampleCode.xUnit\bin\Debug\SampleCode.xUnit.dll
xUnit.net MSBuild runner (32-bit .NET 4.0.30319.269)
xunit.dll: Version 1.9.1.1600
Test assembly: C:\TalentQ\Experiments\UnitTestAnalysis\SampleCode.xUnit\bin\Debug\SampleCode.xUnit.dll
Tests: 4, Failures: 0, Skipped: 0, Time: 0.041 seconds
========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========

The MSBuild task can be configured like the console runner meaning that XML/HTML results can also be saved too. See the documentation for more details.


Another useful thing is that, because it integrates into MSBuild, any failed tests will appear as errors in the IDE error list so by definition this would make it a failed build. The only slight oddity though is that, in its current form (version 1.9.1), double-clicking the errors in the error list does not take you to the correct source code as line numbers given are referring to the project file not source files.


Additional Runners


xUnit.net also provides these test runners as standard:



Performance


Performance of running tests seems to be faster than MSTest, even with a significant number of tests to execute.


Reports


Apart from the output represented by various test runners, an XML report can be produced by either the console or MSBuild runner. Once in an XML format, this can then be transformed into another format, e.g. a HTML file to make it human readable or a *.trx (MSTest) output file so that Visual Studio can understand it.


Fortunately xUnit.net is able to do this transformation for you as long as you provide the XSLT stylesheet to use. Out of the box the following stylesheets are provided:



  • HTML – transforms the XML report into a HTML, human-readable report
  • NUnit – transforms the XML report into the same format that NUnit uses

Documentation


This in my opinion is where xUnit.net falters. Because this is a newer framework documentation is thin on the ground, especially when compared to NUnit. Usually though the features are simple enough to figure out and there is sample code provided in the CodePlex repository, but you may also have to do some searching around on the internet for an explanation of some things.


Extensibility


One of the big selling points of xUnit.net is its extensibility which is far greater than either MSTest or NUnit. Some examples are:


Report Transformations


By default the console runner can provide XML, HTML or NUnit report output, but this is actually configurable by defining further command line switches mapped to a suitable XSLT stylesheet to transform in into another format (e.g. *.trx (MSTest) format).


xUnit.net Extensions


The entire xUnit.net extensions assembly is a perfect example of its extensibility. For instance [Theory] methods are actually specialised [Fact] methods that do some additional work.


More Assertions


If there are not enough assertion functions for your liking you can implement more by extending the Assertions class rather than having to write your own wrappers for it. For example:




   1: public static class MyAssertions 
   2: {
   3:     // By using extension methods you can add more assertions
   4:     public static void Test(this Assertions assert)
   5:     { 
   6:         Assert.True(true);
   7:     }
   8: }
   9:  
  10: // By deriving from TestClass a modifiable Assert class becomes available 
  11: public class CalculatorTests : TestClass 
  12: {
  13:     [Fact]
  14:     public void CustomAssert()
  15:     {
  16:         // This is our own assertion method
  17:         Assert.Test();
  18:     }
  19: }

My Opinion


This is a tricky one. Whereas I felt that NUnit was miles ahead of MSTest, the difference between NUnit and xUnit.net is a lot smaller. To be fair you could pick either one and be extremely productive so it all comes down to nit-picking.


Both NUnit and xUnit.net have their benefits and each have a few disadvantages but in the end, after much careful thought, I’ve decided to use xUnit.net as my primary test framework for the following reasons:



  1. I like the fact that XSLT stylesheets are provided with the framework so I don’t have to define my own HTML report format based on the XML output. And if I wanted to change the layout of the report I would at least have something to modify as a base.
  2. Overall the MSBuild task is a great way of integrating xUnit.net into the build process. Whereas MSTest and NUnit could be run as a task the fact was that they were just starting a new process; the only way you would know your tests had failed was by checking the exit code of the test runner, which wouldn’t tell you anything useful.
  3. The extensibility of framework is a real plus point. I haven’t needed to extend any features yet – consider that a testament to the basics it got right – but it’s nice to know that it is there if needed.
  4. Finally I just feel that it has a lot of potential. It may have some niggles to iron out but I feel confident that they will be.

All of the above are very minor points; like I said I could have just as easily went with NUnit, but xUnit.net just edged ahead in my opinion.

Sunday 2 September 2012

Testing Framework Review: NUnit

In a previous post I reviewed MSTest. This time I will focus on NUnit. NUnit is an open-source testing framework that has been around for a long time – in fact I think there was a time when this was the only test framework for .NET - and is very mature and stable. From the NUnit website:

NUnit is a unit-testing framework for all .Net languages. Initially ported from JUnit, the current production release, version 2.6, is the seventh major release of this xUnit based unit testing tool for Microsoft .NET. It is written entirely in C# and has been completely redesigned to take advantage of many .NET language features, for example custom attributes and other reflection related capabilities. NUnit brings xUnit to all .NET languages.

Integration

NUnit is a separate project meaning that direct Visual Studio support is not provided. However Visual Studio 2012 will allow different frameworks apart from MSTest to be used as the primary unit testing framework - this includes TFS builds too.

In the meantime, the following steps are required:

Download from NuGet

NuGet provides two packages for NUnit:

The NUnit package contains the core of the framework while the NUnit.Runners contains the various test runners needed to run the test assemblies.

Adding these packages to a Visual Studio project is very simple as NuGet will automatically download the latest versions and insert the correct project references required.

One initial gotcha though is that all the test runners by default assume the .NET 2.0 CLR is the correct runtime environment to use, so if you are using the .NET 4 CLR you will have to update all the *.config files to use the correct framework version; simply a matter of commenting out one line in each *.config file, though there are several to modify.

Project Items and Snippets

Unlike MSTest which provides project items and snippets with the IDE, NUnit does not provide any by default. However these items are not difficult to create yourself if required.

Standalone

Although some initial setup is required one possible benefit is that NUnit is a standalone framework - it can be run anywhere without requiring installation, simply by copying the correct files.

Team Build

TFS 2012 will be able to use the same Unit Test plugin model that Visual Studio 2012 uses meaning in future it will be a lot easier to integrate NUnit into the Team Build process.

Until then though it is possible to use NUnit within Team Build but only via a custom build activity and translating the NUnit XML output into MSTest results. This webpage explains how it is possible to do it, though the process looks quite longwinded to me.

Writing Tests

Tests are written like this in NUnit:

   1: using System;
   2: using System.Collections.Generic;
   3: using System.Linq;
   4: using System.Text;
   5: using NUnit.Framework;
   6:  
   7: namespace SampleCode.NUnit
   8: {
   9:     // Denotes a Test Class for NUnit to find
  10:     [TestFixture]
  11:     public class CalculatorTests
  12:     {
  13:         // Denotes a Test Method for NUnit to run        
  14:         [Test]
  15:         public void Add_AddOneAndTwo_ReturnsThree()
  16:         {
  17:             var result = Calculator.Add(1, 2);
  18:  
  19:             // Assertions can be written with a fluent API to make them more descriptive
  20:             Assert.That(result, Is.EqualTo(3));
  21:         }
  22:  
  23:     }
  24: }

There are a much wider variety of assertions provided by NUnit compared to MSTest. There is also a fluent/constraint API provided which allows a more descriptive style of writing if you find that useful.


Data Driven Tests


NUnit supports data-driven tests by writing parameterised test methods and decorating them with special attributes like so:



   1: [Test]
   2: [TestCase(1, 2, 3)]
   3: [TestCase(5, 10, 15)]
   4: [TestCase(30, 2, 32)]
   5: public void Add_AddDataValues_ReturnsExpectedResult(int first, int second, int expected)
   6: {
   7:     var actualResult = Calculator.Add(first, second);
   8:  
   9:     Assert.That(actualResult, Is.EqualTo(expected));
  10: }

Unlike MSTest, NUnit sees this as three separate tests and will display it as such in the test runners.


It is also possible to write a data-driven test by defining a data source using the [TestCaseSource] attribute which defines a property/method which returns an enumerable collection of object values to pass in as parameters.

The only thing that NUnit does not provide out-of-the-box is the ability to store data values and load from a file/external source, only code values can be used. However, using the [TestCaseSource] attribute utility methods can be created by yourself to do that.


Running Tests


Until Visual Studio 2012 comes out NUnit tests cannot be run directly via the IDE but there are a number of other options available.


The console runner is the most basic test runner available and works from the command line.


NUnitConsole


The GUI runner is a standalone application with it's own user interface. Tests are represented in a tree view along with their results and any failures are reported on the right-hand side. Notice also that data-driven tests are split further down into more tests to run.


NUnitGUI


A nice feature of the GUI runner is that it is able to detect changes in the test assembly when it is rebuilt. When a change is detected, the GUI runner can be configured to reload the assembly and automatically run the last set of tests to allow for a continuous testing strategy.


It is also possible to run NUnit via an MSBuild task, e.g. as an after-build step. This is done by simply executing the console runner using the <Exec> task, similar to this:



   1: <Target Name="AfterBuild">
   2:     <Exec Command="..\packages\NUnit.Runners.2.6.1\tools\nunit-console.exe $(TargetPath)" />
   3: </Target>

Build output then appears as follows:

------ Build started: Project: SampleCode, Configuration: Debug Any CPU ------
SampleCode -> C:\Experiments\UnitTestAnalysis\SampleCode\bin\Debug\SampleCode.dll
------ Build started: Project: SampleCode.NUnit, Configuration: Debug Any CPU ------
SampleCode.NUnit -> C:\Experiments\UnitTestAnalysis\SampleCode.NUnit\bin\Debug\SampleCode.NUnit.dll
NUnit-Console version 2.6.1.12217
Copyright (C) 2002-2012 Charlie Poole.
Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov.
Copyright (C) 2000-2002 Philip Craig.
All Rights Reserved.

Runtime Environment -
OS Version: Microsoft Windows NT 6.1.7601 Service Pack 1
CLR Version: 4.0.30319.269 ( Net 4.0 )

ProcessModel: Default DomainUsage: Single
Execution Runtime: net-4.0
....
Tests run: 4, Errors: 0, Failures: 0, Inconclusive: 0, Time: 0.103 seconds
Not run: 0, Invalid: 0, Ignored: 0, Skipped: 0

========== Build: 2 succeeded or up-to-date, 0 failed, 0 skipped ==========


Performance


Performance of running tests seems to be faster than MSTest, even with a significant number of tests to execute.


Reports


Apart from the output represented by various test runners, an XML report can be produced by either the console or GUI runner. Once in an XML format, this can then be transformed into another format, e.g. a HTML file to make it human readable or a *.trx (MSTest) output file so that Visual Studio can understand it.

Unfortunately no sample XSL stylesheets are provided as standard by the NUnit package so this work has to be carried out by yourself or by searching on the Internet for a suitable one.


Extensibility


There are some extensibility points within NUnit but a lot of the most common features are provided as standard so there is very little else to require from it.


My Opinion


In my opinion NUnit is a lot better than MSTest. NUnit is very stable, fast, well supported and documented and supports many of the use case scenarios that you would typically use day to day. Although MSTest beats it in terms of IDE integration even without the new Unit Test Adapter it is still very easy to setup and use; the fact that the GUI runner automatically reloads assembly changes means you can have an almost-continuous test setup.


And for a while I was perfectly happy with using NUnit, until I found out about xUnit.net


More next time!