Here’s an example, minus any domain noise, that demonstrates the whole thing.

Let’s say there’s an interface IJoker which exposes an event JokeMade.

public interface IJoker
{
event EventHandler< JokeEventArgs > JokeMade;
}

public class JokeEventArgs : EventArgs
{
public string Joke { get; private set; }

public JokeEventArgs(string joke)
{
this.Joke = joke;
}
}

And there’s a class Batman which takes an object implementing IJoker as argument in its constructor.

public class Batman
{
private IJoker joker;

public Batman(IJoker joker)
{
this.joker = joker;
this.joker.JokeMade += (sender, e) =>
{
this.LatestJoke = e.Joke;
};
}

public string LatestJoke { get; private set; }
}

It hooks up a handler to the JokeMade event and updates the value of LatestJoke property with whatever joke is made.

So, here’s what the test would look like:

[TestMethod()]
public void BatmanConstructorTest()
{
using (Mockery mocks = new Mockery())
{
IJoker mockJoker = mocks.NewMock< IJoker >();
Expect.Once.On(mockJoker).EventAdd(“JokeMade”, Is.Anything);

Batman testBatman = new Batman(mockJoker);

string expectedJoke = “Bug-free code!”;
Fire.Event(“JokeMade”).On(mockJoker).With(mockJoker, new JokeEventArgs(expectedJoke));

Assert.AreEqual(expectedJoke, testBatman.LatestJoke);
}
}

Notice the call to EventAdd and Fire.Event.

That’s it, hope this helps.

class Program
{
static void Main(string[] args)
{
ICanMove monkey = new Monkey();
monkey.Move();
}
}

public interface ICanMove
{
void Move();
}

public partial class Monkey : ICanMove
{
}

public partial class Monkey
{
public void Move()
{
Console.WriteLine(“Moved”);
}
}

Options:

1. Compiler error.
2. “Moved” will be printed.

Answer is b.

How is it useful?

Well, we can apply the same concept to test code that relies upon an auto-generated proxy for a web-service.

Here’s an example to explain what I mean.

Let’s say you have a class that uses a web-service.

public class ServiceUser
{
public void UseService(ServiceProxy proxy)
{
proxy.DoSomething();
}
}

The class definition for ServiceProxy was generated using a tool (e.g. WSDL).

public partial class ServiceProxy
{
public void DoSomething()
{
// Some code here
}
}

In a test for UseService we want to avoid calling the actual web-service. There are various possible reasons why – performance, usage limits on the web-service, etc.

If we introduce an interface IService like the following:

public interface IService
{
void DoSomething();
}

And modify ServiceProxy to implement that interface:

public partial class ServiceProxy : IService
{
public void DoSomething()
{
// Some code here
}
}

And also modify ServiceUser.UseService to accept an object implementing that interface:

public class ServiceUser
{
public void UseService(IService proxy)
{
proxy.DoSomething();
}
}

Then, to test UseService we can create a mock-object implementing IService and pass it into UseService method.

[TestMethod()]
public void UseServiceTest()
{
using (Mockery mocks = new Mockery())
{
IService mockService = mocks.NewMock();
Expect.Once.On(mockService).Method(“DoSomething”);
ServiceUser target = new ServiceUser();
target.UseService(mockService);
}
}

However it is a good idea to avoid making changes to the auto-generated code for ServiceProxy because they’ll be lost as soon as the proxy is re-generated using the tool.

So that’s where the concept I mentioned in the beginning can help.

Instead of modifying the auto-generated code, just introduce the following empty partial class definition.

public partial class ServiceProxy : IService
{
}

The actual auto-generated ServiceProxy class definition stays the same as that generated by the tool:

public partial class ServiceProxy
{
public void DoSomething()
{
// Some code here
}
}

That’s it and now you can safely test UseService.

TraceCheckingListener is a custom TraceListener which checks each incoming trace message for the presence of credit-card numbers and causes the trace to fail by throwing an exception if one is found.

public class TraceCheckingListener : TraceListener
{
private const string CreditCardRegEx = @”(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|6(?:011|5[0-9][0-9])[0-9]{12}|3[47][0-9]{13}|3(?:0[0-5]|[68][0-9])[0-9]{11}|(?:2131|1800|35\d{3})\d{11})”;
private Regex regex;

public TraceCheckingListener()
{
this.regex = new Regex(CreditCardRegEx, RegexOptions.Compiled);
}

private bool ContainsCreditCardNumber(string text)
{
return (!String.IsNullOrEmpty(text)) && this.regex.IsMatch(text);
}

public override void Write(string message)
{
if (this.ContainsCreditCardNumber(message))
throw new InvalidOperationException(“Sensitive credit-card information cannot be logged.”);
}

public override void WriteLine(string message)
{
if (this.ContainsCreditCardNumber(message))
throw new InvalidOperationException(“Sensitive credit-card information cannot be logged.”);
}
}

It currently checks for Visa, MasterCard, American Express, Discover, Diners Club and JCB credit-cards.

TraceChecker is a small utility class which can be instantiated in a C# using block to install the TraceCheckingListener while the using block executes and remove it when it’s done.

public class TraceChecker : IDisposable
{
private TraceCheckingListener traceCheckingListener;

public TraceChecker()
{
this.traceCheckingListener = new TraceCheckingListener();
Trace.Listeners.Insert(0, this.traceCheckingListener);
}

#region IDisposable Members

public void Dispose()
{
if (this.traceCheckingListener != null)
{
Trace.Listeners.Remove(this.traceCheckingListener);
this.traceCheckingListener = null;
}
}

#endregion
}

One way to make use of these classes is to introduce the following class in your unit-test suite assembly.

[TestClass]
public class TraceCheckerInstaller
{
private static TraceChecker traceChecker;

[AssemblyInitialize]
public static void InstallTraceChecker(TestContext context)
{
traceChecker = new TraceChecker();
}

[AssemblyCleanup]
public static void UninstallTraceChecker()
{
if (traceChecker != null)
{
traceChecker.Dispose();
traceChecker = null;
}
}
}

InstallTraceChecker will be called only once when the assembly containing the unit-tests is loaded so we use the opportunity to install the custom trace-listener. UninstallTraceChecker will be called once when the assembly is being unloaded which we use to remove the custom trace-listener.

Alternately, you may also utilize the following approach in individual unit-tests.

[TestMethod]
public void MyTestMethod()
{
using (new TraceChecker())
{
// Write code to test whatever you want to test here.
// This test will fail if any method called from here
// attemps to trace sensitive information to the log.
}
}

public interface IAdder
{
string Add(params string[] items);
}

And consider that we have to test the following function which invokes Add with two arguments.

public string AddStrings(string one, string two, IAdder adder)
{
return adder.Add(one, two);
}

The expectation created below is incorrect:

string[] args = new string[] { “FOO”, “BAR” };
IAdder adder = mocks.NewMock();
string expected = “FOOBAR”;

Expect.Once.On(adder).Method(“Add”).With(args).Will(Return.Value(expected));

string actual;
actual = target.AddStrings(args[0], args[1], adder);
Assert.AreEqual(expected, actual);

It will cause NMock to generate the following exception because NMock is expecting two distinct arguments to Add with values “FOO” and “BAR” instead of an array of strings containing “FOO” and “BAR”.

NMock2.Internal.ExpectationException occurred
Message=”unexpected invocation of adder.Add()\r\nExpected:\r\n 1 time: adder.Add(equal to \”FOO\”, equal to \”BAR\”), will return \”FOOBAR\” [called 0 times]\r\n”

You need to change the expectation so that NMock compares the string-array.

Expect.Once.On(adder).Method(“Add”).With(Is.EqualTo(args)).Will(Return.Value(expected));

That’ll do the trick.

customer.NewOrder
.With(1, “ONE”)
.With(2, “TWO”)
.With(3, “THREE”)
.PriorityRush();

The API used above is clearly more readable than:

Order o1 = new Order();
customer.AddOrder(o1);
OrderItem item1 = new OrderItem(1, “ONE”);
o1.Add(item1);
OrderItem item2 = new OrderItem(2, “TWO”);
o1.Add(item2);
OrderItem item3 = new OrderItem(3, “THREE”);
o1.Add(item3);
o1.SetRush();

Another reason I like them is that fluent style APIs are easier to pick up. You can rely on intellisense to guide you more as you have to worry about lesser number of class and method names.

So they’re nice, but I hate to see code like the following that has to do a lot of setting up before you can actually make a call to the function you wish to test from your unit-test:

[TestMethod()]
public void PlacePriorityOrderTest()
{
using (Mockery mocks = new Mockery())
{
int itemID = 42;
string itemDescription = “SOMETHING”;

Program target = new Program();

// Start setting up NMock expectations…
ICustomer customer = mocks.NewMock();
IOrderActions mockOrderActions = mocks.NewMock();
Expect.Once.On(customer).GetProperty(“NewOrder”).Will(Return.Value(mockOrderActions));
IOrderActions mockOrderItemActions = mocks.NewMock();
Expect.Once.On(mockOrderActions).Method(“With”).With(itemID, itemDescription).Will(Return.Value(mockOrderItemActions));
Expect.Once.On(mockOrderItemActions).Method(“PriorityRush”);
// End setting up NMock expectations…

// Call the function we wish to test
target.PlacePriorityOrder(customer, itemID, itemDescription);
}
}

Here is the function that the test above is exercising:

public void PlacePriorityOrder(ICustomer customer, int itemID, string itemDescription)
{
customer.NewOrder.With(itemID, itemDescription).PriorityRush();
}

The test is just making sure that the item-id and item-description passed to PlacePriorityOrder are used to create a new order with priority-rush. There’re probably going to be many tests that exercise the same fluent-API and they’d all be doing similar setting up of mock objects.

It would be better if the expectation was specified in a fluent manner as well.

[TestMethod()]
public void PlacePriorityOrderTest2()
{
using (Mockery mocks = new Mockery())
{
int itemID = 42;
string itemDescription = “SOMETHING”;

Program target = new Program();

MockCustomer mockCustomer = MockCustomer.Record(mocks);
mockCustomer.NewOrder.With(itemID, itemDescription).PriorityRush();

target.PlacePriorityOrder(mockCustomer.Start(), itemID, itemDescription);
}
}

Notice the call to MockCustomer.Record to return a mock ICustomer instance that can be used to record calls to various methods that the test expects to be made. Also note that mockCustomer.Start is used to retrieve the mock ICustomer instance that’s actually used by the function under test.

The zip archive here contains code demonstrating how this can be done.

Let’s restrict our problem to involve just 2 classes for the purpose of this article. Assume there’s already a class named Transaction and we’re interested in testing its CompleteTransaction method.

public class Transaction
{
public void CompleteTransaction()
{
DeviceManager.Instance.OpenCashDrawer();
}
}

In our test we plan to ensure that CompleteTransaction calls the OpenCashDrawer method of DeviceManager.

public sealed class DeviceManager
{
private static readonly DeviceManager instance = new DeviceManager();

private DeviceManager()
{
}

public static DeviceManager Instance
{
get
{
return instance;
}
}

public void OpenCashDrawer()
{
// Code for opening cash-drawer will go here.
Console.WriteLine(“CashDrawer opened…”);
}

}

DeviceManager is a singleton and there lies our problem. If there was an interface that DeviceManager implemented and CompleteTransaction took an object implementing that interface as argument we could have used NMock to mock that interface and created expectations in our test to expect a call to its OpenCashDrawer method when CompleteTransaction is called. We want to reduce the code churn so another alternative is needed. Changing the singleton semantics of DeviceManager or changing the CompleteTransaction method’s signature – are alternatives which will potentially require modification of a lot of code and testing it.

But having an interface in the picture will make our job easier so here’s what we can do.

1. Extract interface: We can extract an interface containing all the methods contained in DeviceManager class. Let’s say, we’re going to call it IDeviceManager.
2. Change types: We can then modify the type of static instance field and static Instance property to be IDeviceManager instead of DeviceManager.
3. Plant mock: In our test for CompleteTransaction method if we could somehow plant a mock object implementing IDeviceManager in the DeviceManager.instance field, we can then create an expectation in our test saying that expect a call to OpenCashDrawer method.

Extract interface

This is easy to do in our example. In the real world, especially for a class that has been around for years, there could potentially be hundreds of methods. If that’s the case you have, take a look at the DevExpress Refactor add-in for Visual Studio which just requires you to right-click on a class and select “Extract interface”.

In our example, here’s what we end up with:

public sealed class DeviceManager : IDeviceManager
{
private static readonly DeviceManager instance = new DeviceManager();

private DeviceManager()
{
}

public static DeviceManager Instance
{
get
{
return instance;
}
}

public void OpenCashDrawer()
{
// Code for opening cash-drawer will go here.
Console.WriteLine(“CashDrawer opened…”);
}

}

public interface IDeviceManager
{
void OpenCashDrawer();
}

At this point all of your code should compile just fine.

Change types

We simply change the type of instance field and Instance property to be IDeviceManager.

public sealed class DeviceManager : IDeviceManager
{
private static IDeviceManager instance = new DeviceManager();

private DeviceManager()
{
}

public static IDeviceManager Instance
{
get
{
return instance;
}
}

public void OpenCashDrawer()
{
// Code for opening cash-drawer will go here.
Console.WriteLine(“CashDrawer opened…”);
}

}

public interface IDeviceManager
{
void OpenCashDrawer();
}

Again at this point the code should compile just fine. If it doesn’t, as would be the case where you have code that saves an instance of DeviceManager in a local variable before doing stuff with it, you’ll have to refactor that code to get rid of all compilation errors.

Plant mock

How do we plant a mock-object in the private static field DeviceManager.instance?

1. We start by making use of the private-accessors feature of Visual Studio 2008. Right-click on DeviceManager class and select “Create Private Accessors”. You can read more about private accessors here. The basic idea is that a DeviceManager_Accessor class will be created mirroring the public methods of DeviceManager but additionally also exposing its private and protected fields. Internally a DeviceManager_Accessor object manages a DeviceManager object and forwards all method calls and field accesses to it. You can also create private-accessors from the Visual Studio command-prompt using “publicize ”.
2. We write our test to create a mock-object implementing IDeviceManager and plant it in the DeviceManager’s static instance field using DeviceManager_Accessor.

   IDeviceManager mockDeviceManager = mocks.NewMock< IDeviceManager>();
   DeviceManager_Accessor.instance = mockDeviceManager;

3. But there’s something to watch out for. It is possible that this test runs as part of a suite of tests so you want to ensure that DeviceManager.Instance returns a normal DeviceManager object after your test has finished executing. It is not sufficient to set DeviceManager_Accessor to null – you must restore the DeviceManager_Accessor.instance field to whatever its value was before you set it to a mock object. Since we want to ensure that the instance static field gets reset even if our test code throws an exception, we do the resetting in a finally block. Here’s what the test-method’s body would look like.

   using (Mockery mocks = new Mockery())
   {
   // save
   IDeviceManager prevDeviceManager = DeviceManager_Accessor.instance;

   try
   {
   // plant
   IDeviceManager mockDeviceManager = mocks.NewMock();
   DeviceManager_Accessor.instance = mockDeviceManager;

   // TODO: write test code here.
   }
   finally
   {
   // restore
   DeviceManager_Accessor.instance = prevDeviceManager;
   }
   }

The test

Now that we have everything in place, let’s write the actual test code. Before calling CompleteTransaction, we create an NMock expectation to ensure that OpenCashDrawer is called on the mock IDeviceManager object.

[TestMethod()]
public void CompleteTransactionTest()
{
using (Mockery mocks = new Mockery())
{
// save
IDeviceManager prevDeviceManager = DeviceManager_Accessor.instance;

try
{
// plant
IDeviceManager mockDeviceManager = mocks.NewMock();
DeviceManager_Accessor.instance = mockDeviceManager;

// we expect OpenCashDrawer to be called
Expect.Once.On(mockDeviceManager).Method(“OpenCashDrawer”);

// the actual
Transaction target = new Transaction();
target.CompleteTransaction();
}
finally
{
// restore
DeviceManager_Accessor.instance = prevDeviceManager;
}
}

}

Run the test and it should pass. Change the body of CompleteTransaction method to not make a call to OpenCashDrawer and the test should fail.

Recap of the approach

1. Extract an interface from the singleton class.
2. Modify the singleton class to implement the newly created interface.
3. Modify the type of the static field (= VB.NET shared) holding a reference of the singleton class, and the return-type of the method/property returning the singleton to be same as the newly created interface.
4. Generate an accessor assembly for the assembly containing the singleton class for use in your unit-tests.
5. Write your unit-test to create a mock object implementing the newly introduced interface and plant it in the static field of the singleton class.
6. Create necessary expectations on various methods on the newly introduced interface which you expect to be called by the function under test.
7. Once your test is finished, ENSURE that the previous singleton is restored (using finally block).

If, however, you’re in the process of writing a new singleton class in your project, consider introducing an interface and create a façade which everyone would use to obtain an instance of your class implementing that interface. This will probably save you from having to revisit this article in the future

Click here to download a zip archive containing the code shown in this article.

Using Pex is as easy as right-clicking on a function in Visual Studio and selecting “Run Pex Explorations”. Pex takes a little while running your function and then displays a table with various values that can be used to test your function.

However if your legacy code happens to be in VB.NET, you cannot just right-click on a function to have Pex generate all unit-tests for you. So that’s where I hope this article will help you.

First, let’s define a scenario. Imagine there’s a class called Transaction and a class called PaymentMethod. A transaction contains various payment-methods. A PaymentMethod indicates whether it requires the cash-drawer to be opened or not (e.g. it doesn’t make sense to pop cash-drawer for a credit-card while it does for cash and debit-card). There’s a read-only property PopCashDrawer on Transaction which returns true if any of the payment-methods requires the cash-drawer to be opened.

Public Class PaymentMethod

Private mPopCashDrawer As Boolean

Public Property PopCashDrawer() As Boolean
Get
Return Me.mPopCashDrawer
End Get
Set(ByVal value As Boolean)
Me.mPopCashDrawer = value
End Set
End Property

End Class

Public Class Transaction

Private mPaymentMethods() As PaymentMethod

Public Property PaymentMethods() As PaymentMethod()
Get
Return Me.mPaymentMethods
End Get
Set(ByVal value As PaymentMethod())
Me.mPaymentMethods = value
End Set
End Property

Public ReadOnly Property PopCashDrawer() As Boolean
Get
Dim pop = False
For Each pm As PaymentMethod In Me.PaymentMethods
pop = pop OrElse pm.PopCashDrawer
Next
Return pop
End Get
End Property

End Class

To have Pex generate unit-tests for you, here’s what you need to do:

• First to get started writing unit-tests, just right-click on Transaction in Visual Studio and select “Create Unit Tests”. Make sure you select “Create a new Visual C# project” for Output Project in the dialog that pops up.
• Next, in the generated class TransactionTest add the following parameterized unit-test (PUT). This guides Pex to come up with different values of arguments to this method which will exercise all code-paths in PopCashDrawer property. Transaction.PopCashDrawer depends upon the PaymentMethods so we take the array of PaymentMethods as argument to our PUT and set it on the transaction before calling PopCashDrawer. The PexAssume.IsNotNull line further guides Pex to say that we don’t really care about the case when transaction is null because we’re really interested in testing PopCashDrawer method.

  [PexMethod]
  public bool PopCashDrawerPUT(Transaction transaction, PaymentMethod[] paymentMethods)
  {
  PexAssume.IsNotNull(transaction);
  transaction.PaymentMethods = paymentMethods;
  return transaction.PopCashDrawer;
  }

• Next, just right-click on PopCashDrawerPUT and select “Run Pex Explorations”. Pex will then display a table with various values of arguments and the results it got in each case.
• However since the VB assembly is separate from the C# test-project, Pex will display an icon indicating that it didn’t explore some methods because they were uninstrumented.
• Make sure you include all methods displayed as uninstrumented and run Pex explorations again.
• This time around Pex would show 7 different test-cases that it identified.
• A file named TransactionTest.PopCashDrawerPUT.g.cs would be generated containing unit-tests for those 7 cases. Take a look at that class to see how much work it saved you.
• You can run the generated unit-tests by going to Test->Run->All Tests in Solution from the main-menu in Visual Studio.
• Pex would discover inputs which cause PopCashDrawer to throw a NullReferenceException. Determining fixes for those cases is left as an exercise to the reader

Download and try out Pex, if you haven’t already!

There are two ways you can go about mocking indexers defined on interfaces when using NMock.

1. You can use the Get property to describe what should be returned when a particular parameter is passed. The following expectations for example, cause “xxx” to be returned when foo[“aaa”] or foo[“bbb”] is called.

   Expect.Once.On(foo).Get["aaa"].Will(Return.Value(“xxx”));
   Expect.Once.On(foo).Get["bbb"].Will(Return.Value(“xxx”));

   This approach works fine in most circumstances. However you are required to provide all the values with which the indexer can be invoked. This presents a problem in the scenario where you need to return a particular value irrespective of the value of the input parameter.

2. Indexers are implemented under the hood as methods so NMock’s support for mocking methods can be used to mock indexers. An indexer definition is munged by the compiler to a pair of get_Item and set_Item methods. When you call foo[“aaa”], it is munged by the compiler to a call to the get_Item method on foo with “aaa” as the argument.

   So here’s what you can do to make sure that “xxx” is returned irrespective of the value of the parameter passed to the indexer.

   Stub.On(foo).Method(“get_Item”).Will(Return.Value(“xxx”));

   Now any call of the form foo[<BLAH>] will return “xxx”.

Consider the following interface:

public interface IFoo
{
void Bar(out int a, ref int b);
}

“Bar” method takes one “out” parameter and another “ref” parameter.

To start mocking “IFoo” you would obviously first create a new mock object implementing interface “IFoo”.

IFoo aFoo = mocks.NewMock< IFoo >();

We store it in a variable named “aFoo”.

Here’s how you would set up an expectation to ask NMock to expect a call to method “Bar” on “aFoo” object with an “out” parameter and a “ref” parameter with 2 as its value.

Expect.Once.On(aFoo)
.Method(“Bar”).With(Is.Out, 2)
.Will(new SetNamedParameterAction(“a”, 10),
new SetNamedParameterAction(“b”, 20));

The actions specified in the “Will” part cause the “out” and “ref” parameters to be set to values 10 and 20 respectively after “Bar” is called on “aFoo”.

int a, b = 2;
aFoo.Bar(out a, ref b);

// At this point “a” will be set to 10 and “b” will be set to 20 because
// of the expectation specified above.

Hope this helps.

For the purpose of this article let us consider a simple Windows Forms application (download link below). The application allows the user to provide two inputs and then either add them or subtract them. Simple, right?

The application

Here’s the code for the event-handlers of interest to us:

private void MainForm_Load(object sender, EventArgs e)
{
this.lblAnswer.Text = “0″;
}

private void btnAdd_Click(object sender, EventArgs e)
{
this.lblAnswer.Text = Convert.ToString(this.numericUpDown1.Value + this.numericUpDown2.Value);
}

private void btnSubtract_Click(object sender, EventArgs e)
{
this.lblAnswer.Text = Convert.ToString(this.numericUpDown1.Value – this.numericUpDown2.Value);
}

The handler for the load event of the form just sets the answer label to display “0”. The handler for the click event of each of the buttons retrieves the selected values from the numeric drop-downs, applies the appropriate operation, and writes the result into the label.

The tests

In order to write tests for this application, you can start by right-clicking on the class of the form (in this case MainForm), and selecting “Create Unit Tests…”. Hit “OK” on the dialog that pops up to create unit-tests in a separate project. Another dialog will pop up asking for the name of the test project. Just hit “Create”.

This will cause Visual Studio to do some heavy lifting for us and generate accessors to allow us to call methods and properties defined on MainForm, from our tests. We don’t have to write code for accessors using the Reflection API ourselves – so this is extremely cool. Doing it on our own is quite painful (proof).

Delete all the tests marked with the TestMethod attribute in the generated class because we’re going to write our own.

The first one is pretty simple. We expect the answer label to display a “0” when the form is initially loaded – so let’s test that.

///

[TestMethod()]
[DeploymentItem("AppUnderTest1.exe")]
public void MainForm_LoadTest()
{
MainForm_Accessor target = new MainForm_Accessor();
target.MainForm_Load(null, null);
Assert.AreEqual(“0″, target.lblAnswer.Text, “Initial answer is zero”);
}

Notice that we can call MainForm_Load directly (no ConstructorInfo, MethodInfo – reflection stuff required).

Once that’s done we can just check the text displayed in the answer label and make sure it is “0”.

We can take the same approach to call the click event handlers of the buttons and check the results for addition/subtraction.

Since there are various cases to test, I have a separate function GetTestTable that returns a two dimensional array where each row contains the two test-inputs, result of subtraction, and result of addition – in that order.

public int[,] GetTestTable()
{
// Format of each row:
// A, B, (A-B), (A+B)
int[,] table =
{
{0, 0, 0, 0},
{10, 0, 10, 10},
{0, 10, -10, 10},
{-10, 0, -10, -10},
{0, -10, +10, -10},
{10, 10, 0, 20},
{-10, -10, 0, -20},
{-10, 10, -20, 0},
{10, -10, 20, 0}
};
return table;
}

Following is the function that actually does the testing. We basically process each row returned by GetTestTable one by one. First we set the two inputs on the numeric drop-downs. Next we call the click event-handlers of both buttons verifying what is in the answer label against what we expect. Again notice that we can directly invoke the event handlers and even access properties of the answer label (lblAnswer).

///

[TestMethod()]
[DeploymentItem("AppUnderTest1.exe")]
public void AddSubtractTest()
{
MainForm_Accessor target = new MainForm_Accessor();

int[,] table = this.GetTestTable();

for (int i = 0; i < table.GetUpperBound(0); i++)
{
int a = table[i, 0],
b = table[i, 1],
subtract = table[i, 2],
add = table[i, 3];

target.numericUpDown1.Value = a;
target.numericUpDown2.Value = b;

target.btnSubtract_Click(null, null);
int result = Convert.ToInt32(target.lblAnswer.Text);
Assert.AreEqual(subtract, result, String.Format(“Subtract {0} and {1}”, a, b));

target.btnAdd_Click(null, null);
result = Convert.ToInt32(target.lblAnswer.Text);
Assert.AreEqual(add, result, String.Format(“Add {0} and {1}”, a, b));
}
}

To run these tests, select Test->Run->All Tests in Solution from the main-menu in Visual Studio. The “Test Results” window in Visual Studio should show that all tests passed.

Summary

There’re multiple ways to go about automating UI testing. You could use an automated testing tool like Mercury Quick Test. However if you want to take things into your own hands and take advantage of greater control, you could write your tests using NUnit or MS-Test and make PInvoke calls to send messages to various controls in the UI of your application under test. You could use the SendKey API in Windows.Forms too.

However if you want to take advantage of knowledge of the internals of the application under test, we have to use Reflection to set properties of the controls, invoke event handlers, call other methods and then test whether this resulted in the changes that we expected. This makes the job extremely painful. I hope this article shows how much easier it is if we leverage Visual Studio Team System to generate accessors for us.

I don’t see why the technique described above cannot be used to test WPF and Silverlight applications as well.

Download
Click here to download the code accompanying this article.