One of the more common reasons that developers tell us of why they don’t unit test is “All of my application is visual controls with code behind. Refactoring all of that code to a .dll that can be united tested will take more time than it is worth.” While it is true that unit testing is easier if your application lives “in code” as a separate assembly, you can still use unit testing in a UI-heavy code base. By judiciously using a mocking framework, you can speed up the process even more.
Consider this form from a WinForm application written in VB.NET.
The grid view has the following code behind :
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
For counter = 0 To DataGridView1.RowCount - 1
If (DataGridView1.Rows(counter).Cells(11).FormattedValue) Then
If (DataGridView1.Rows(counter).Cells(10).Value <> "") Then
TextBox1.Text = FormatCurrency(TextBox1.Text - DataGridView1.Rows(counter).Cells(10).Value, 2)
End If
End If
Next
End Sub
The business logic is intermingled with the visual controls (TextBox1, DataGridView1, etc…). Is there a way to easily unit test this code? The answer is yes. Step one is to add a unit test project to the solution. Step two is to break the sub method into a function method. Once the methods have an input and an output, you can put a unit test on it. For example:
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
For counter = 0 To DataGridView1.RowCount - 1
Dim initialValue = TextBox1.Text
Dim cell0 = DataGridView1.Rows(counter).Cells(11)
Dim cell1 = DataGridView1.Rows(counter).Cells(10)
TextBox1.Text = GetCalculatedValue(initialValue, cell0, cell1)
Next
End Sub
Public Function GetCalculatedValue(initalValue As String, cell0 As DataGridViewCell, cell1 As DataGridViewCell) As String
Dim returnValue As String = initalValue
If (cell0.FormattedValue) Then
If (cell1.Value <> "") Then
initalValue = FormatCurrency(TextBox1.Text - cell1.Value, 2)
End If
End If
Return initalValue
End Function
And we can add a unit test like this:
[TestMethod]
public void GetCalculatedValue_ReturnsExpected()
{
Form1 instance = new Form1();
String baseValue = "$10.00";
DataGridView gridView = new DataGridView();
gridView.Columns.Add("TEST1", "TEST1");
gridView.Columns.Add("TEST2", "TEST2");
gridView.Rows.Add(new DataGridViewRow());
gridView.Rows[0].Cells[0].Value = "$1.00";
gridView.Rows[0].Cells[1].Value = "$2.00";
DataGridViewCell cell0 = gridView.Rows[0].Cells[0];
DataGridViewCell cell1 = gridView.Rows[0].Cells[1];
var actual = instance.GetCalculatedValue(baseValue, cell0, cell1);
var expected = "$8.00";
Assert.AreEqual(expected, actual);
}
Although this test runs green, it is suboptimal because we have to standup lots of objects (DataGridView, Columns, DataGridRow) just to get to the class we are interested in, in this case DataGridViewCell. Instead of generating all of that superfluous code, there is a better way to set the state of only the class we want – enter Mocking frameworks. Mocking frameworks give us the ability to focus only on the subjects under test (SUT) while ignoring everything else.
But there is a catch. There are 2 types of mocking frameworks: ones that generate their code based on inspecting the types and ones that generate their code based on the compiled IL. The former group includes RhinoMocks and Moq . If you try and add Moq to this unit test project and generate a DataGridViewCell like this:
[TestMethod]
public void GetCalculatedValue_ReturnsExpected()
{
Form1 instance = new Form1();
String baseValue = "$10.00";
var mock0 = new Mock<DataGridViewCell>();
mock0.SetupGet(dataGridViewCell => dataGridViewCell.Value).Returns("$1.00");
var mock1 = new Mock<DataGridViewCell>();
mock1.SetupGet(dataGridViewCell => dataGridViewCell.Value).Returns("$2.00");
var actual = instance.GetCalculatedValue(baseValue, mock0.Object, mock1.Object);
var expected = "$8.00";
Assert.AreEqual(expected, actual);
}
You will get an exception
Since we don’t control DataGridViewCell’s code, there is no way to change those properties to overidable/nonvirtual. As a general rule, you only use RhinoMocks/Moq on classes that you can control.
The other type of mocking framework (based on IL) can solve this problem. There are 2 commercial frameworks (JustMock, TypeMock) but they cost $399/year (as of this writing). There is a 3rd framework we can use and it is built into Visual Studio 2012+. It is called the Microsoft Fakes Framework. By adding this to your test project,
you can craft your unit test like so:
[TestMethod]
public void GetCalculatedValue_ReturnsExpected()
{
Form1 instance = new Form1();
String baseValue = "$10.00";
using (ShimsContext.Create())
{
var cell0 = new ShimDataGridViewCell(new StubDataGridViewCell());
cell0.FormattedValueGet = () => { return "$1.00"; };
var cell1 = new ShimDataGridViewCell(new StubDataGridViewCell());
cell1.ValueGet = () => { return "$2.00"; };
var actual = instance.GetCalculatedValue(baseValue, cell0, cell1);
var expected = "$8.00";
Assert.AreEqual(expected, actual);
}
}
and get green. The downside of using Microsoft Fakes is that you need to re-generate the fakes if the code changes. This makes it ideal for faking external libraries that don’t change much (like ADO.NET) but not assemblies that are under active development.
Jamie Dixon's Home 