Better Unit Tests in C#
When you test the right thing, you get better unit tests. Better unit tests often lead to better design, testable design, and easier maintainability of code.
Look at an example of testing a Copy() method in a Person object. You will see that as you unit test this method, you are forced to think. If you think about what you really want to test (instead of just thinking about 100% coverage), and test for that, it will lead you to changing your code for the better.
With a Copy() method, you want to make sure that every property in the Person object is copied. You want to make sure that any new Property added in the future is copied.
Lets see if we can do this. Lets start with our simple example Person object with a Copy() method and lets test the copy method.
using System;
namespace FriendDatabase
{
public class Person
{
#region Properties
public int Age { get; set; }
public String FirstName { get; set; }
public String LastName { get; set; }
#endregion
#region Methods
public Person Copy()
{
Person retPerson = new Person();
retPerson.Age = this.Age;
retPerson.FirstName = this.FirstName;
retPerson.LastName = this.LastName;
return retPerson;
}
#endregion
}
}
Lets list the three most obvious tests for the copy method.
- Age is the same value.
- FirstName is the same value.
- LastName is the same value.
If you are an expert at Unit Testing, you are probably already thinking that there are more tests to run that just these three tests.0
A simple Unit Test
A test for this that would give use 100% code coverage and covers the three most obvious tests would be as follows:
[Test]
public void Person_Copy_Test()
{
// Step 1 - Arrange
Person p = new Person() { FirstName = "John", LastName = "Johnson", Age = 0 };
// Step 2 - Act
Person copy = p.Copy();
// Step 3 - Assert
Assert.AreEqual(p.Age, copy.Age);
Assert.AreEqual(p.FirstName, copy.FirstName);
Assert.AreEqual(p.LastName, copy.LastName);
}
The code coverage is now 100%. But is this a good test? No.
What are the problems with our tests?
Problem 1 – The Unit Test does not guarantee every property is copied
In the Person.Copy() method, comment out the line that copies the Age. Run the test again.
Oops! The test still passes.
What is the problem? Well, int defaults to zero.
Change the age to a value other than zero and try again. The test now fails.
[Test]
public void Person_Copy_Test()
{
// Step 1 - Arrange
Person p = new Person() { FirstName = "John", LastName = "Johnson", Age = 25 };
// Step 2 - Act
Person copy = p.Copy();
// Step 3 - Assert
Assert.AreEqual(p.Age, copy.Age);
Assert.AreEqual(p.FirstName, copy.FirstName);
Assert.AreEqual(p.LastName, copy.LastName);
}
This fixed this one problem.
Is the test good enough now? Of course not.
Problem 2 – The Unit Test does not guarantee every property is copied
Wait, you might be saying that my problem 2 is named the same as problem 1 and you might think this is a typo. It is not a typo.
We still have a similar problem to the first problem.
Imagine a new user developer takes over the code, and decides that a MiddleName property is needed. Go ahead and add a middle name property. Don’t modify the Copy() method yet. Now run your Unit Test again.
Our one test still passes.
Shouldn’t there be a test that fails because the copy is now failing to copy to all properties? Yes there should. We have just identified a new test that actually includes the previous three tests. The goal of our three tests were all the same overall goal. Our three tests were actually slightly wrong. Instead we really had only one test: Test that when Copy() is invoked, all properties should be copied.
Now that we have gain more insight on what we are actually testing, how do we test it? How do we test all properties. One idea might be to use reflection.
[Test]
public void Person_Copy_Test()
{
// Step 1 - Arrange
Person p = new Person() { FirstName = "John", LastName = "Johnson", Age = 25 };
// Step 2 - Act
Person copy = p.Copy();
// Step 3 - Assert
PropertyInfo[] propInfo = typeof(Person).GetProperties();
foreach (var prop in propInfo)
{
object pObj = typeof(Person).GetProperty(prop.Name).GetValue(p, null);
object copyObj = typeof(Person).GetProperty(prop.Name).GetValue(copy, null);
Assert.AreEqual(pObj, copyObj);
}
}
At first this looked like a good idea, because it will check each property for us, even properties added in the future. However, it turns out that because int and string have default values, This test didn’t exactly test what we wanted to test. This test still passes when it should fail and that is a problem.
Remember the test: to test that when Copy() is invoked, all properties should be copied.
We need guarantee that each property was called and to do this. If only we were using an interface, then we could mock the interface and assert that each public property were called…A good rule to live by when developing is if you hear yourself say or you think “if only…” you should actually try implementing the “if only…” you just thought of. So lets do that.
This is a little longer of a solution but a better design, so here are some steps to get there.
- Create an IPerson interface that has the properties and methods we want to guarantee exist.
using System; namespace FriendDatabase { public interface IPerson { int Age { get; set; } String FirstName { get; set; } String MiddleName { get; set; } String LastName { get; set; } IPerson Copy(); void CopyTo(IPerson inIPerson); } } - Change the person object so that you can never get a Person object, you always get an IPerson.
- We also need to be able to mock the instance of IPerson that is getting created by the Copy method and our current design doesn’t allow for that. Lets change our Copy method and add a CopyTo method to make this possible.
using System; namespace FriendDatabase { public class Person : IPerson { #region Constructor /// <summary> /// Nobody should use Person, but on GetPerson() /// which returns and IPerson /// </summary> protected Person() { } #endregion #region Properties public int Age { get; set; } public String FirstName { get; set; } public String MiddleName { get; set; } public String LastName { get; set; } private String NickName { get; set; } #endregion #region Methods public static IPerson GetPerson(string inFirstName, string inMiddleName, String inLastName = null, int inAge = 0) { return new Person() { FirstName = inFirstName, MiddleName = inMiddleName, LastName = inLastName, Age = inAge }; } public IPerson Copy() { IPerson retIPerson = new Person(); CopyTo(retIPerson); return retIPerson; } public void CopyTo(IPerson inIPerson) { inIPerson.Age = this.Age; inIPerson.FirstName = this.FirstName; inIPerson.LastName = this.LastName; } #endregion } } - Now we need a Mocking tool. Download you favorite mocking library (RhinoMocks, NMock2, or MOQ). I am going to use NMock2 which can be downloaded here: NMock2
- Lets put the mocking library in a lib directory in your test project.
- Add a reference to the dll.
- Now lets change our test. Lets go ahead and use the reflection still, but this time, we want to guarantee that each property was called.
[Test] public void Person_Copy_All_Properties_Copied_Test() { // Step 1 - Arrange Mockery mock = new Mockery(); IPerson p = Person.GetPerson("John", "J.", "Johnson", 25); IPerson mockIPerson = mock.NewMock(); PropertyInfo[] propInfo = typeof(IPerson).GetProperties(); // Step 2 - Expect foreach (var prop in propInfo) { Expect.AtLeastOnce.On(mockIPerson).SetProperty(prop.Name); } // Step 3 - Act p.CopyTo(mockIPerson); // Step 4 - Assert mock.VerifyAllExpectationsHaveBeenMet(); }Note: NMock2 requires a slight variation of the Arrange, Act, Assert (AAA) unit test model in that it is more Arrange, Expect, Act, Assert (AEAA), which is just as good and just as clean. One could argue that the expectations are part of the Arrange and I would somewhat agree with that too.
- Ok, now run your test again and it should fail because we are not calling MiddleName in our CopyTo() method. You have now written the correct unit test for the goal.
So by taking time to think of the correct test and Unit Testing the correct test, solving the right problem, we gained a few benefits.
- Better future maintainability
- Better design
- Testable design
Now hopefully you can go and do this when you write your Unit Tests.
Return to C# Unit Test Tutorial
