To a lot of you this may sound pretty familiar. A WindowsApplicationx, with a Form1 containing this kind of code
private void button1_Click(object sender, EventArgs e)
{
label1.Text = MyFunction(textBox1.Text);
}
Later on in the process the essentials of the code are copied into the "real" project. Leaving your disk cluttered with endless Form1's and unused solution's.
This makes a good starting point for TDD. Instead of creating a form1 you start by creating a class library containing a test method which does the same. And a little more.
I'm using nunit as test framework. ReSharper does a great job as well. It recognizes the tests and displays an icon in the gutter. Clicking that fires up the ReSharper test runner.
One of the nice things of this tool is that it catches the console output. Giving you far better possibilities to display messages than a label on some form. Another nice thing is that you can also use the test runner to debug the code under test.
So far I presumably haven't told you much news. But there is another way I found this test runner handy to eliminate all those Form1's.
In my case I am developing a user control. Unit testing on visual things is something under discussion. In the ideal scenario a visual component does not contain any business logic. But some things are just to hard to separate from the UI. In our case the user control contains a couple of treeviews which are initialized from an xmldocument. I just need a test to ensure the control loads the document.
This is not a problem, you can create a user control inside a test method and test the control's methods. Just like this: (DesignerSurface is the user control class)
[Test]
public void TestXmlLoad()
{
DesignerSurface ds = new DesignerSurface();
ds.Store = new ServiceMetaDataMock();
ds.GetServiceData("Test", ServiceType.Get, 1, 0, 0, 0);
Assert.Greater(ds.Store.Size, 0);
}
The test will pass after a succesfull load.
But there is more in the user control which requires testing. There are a lot of drag and drop actions in the treeviews. Testing this has to be done by hand, by a human being. Using the TDD tools I can still avoid a Form1 project and directly test the control itself. Take this "test":
[Test]
public void ShowDesigner()
{
Console.WriteLine("Creating form");
Form container = new Form();
container.Width = 700;
container.Height = 450;
DesignerSurface designer = new DesignerSurface();
designer.Store = new ServiceMetaDataMock();
designer.Dock = DockStyle.Fill;
container.Controls.Add(designer);
designer.GetServiceData("Test", ServiceType.Get, 1, 0, 0, 0);
Console.WriteLine("Form created");
container.ShowDialog();
}
It creates a form on the fly and fills it with the usercontrol. After firing a showdialog the form shows and I can play with it till I have had my fill. All this time the test is still running.
The good thing is that everything in Visual Studio keeps running. Also the test runner, one way to close the form is by clicking it's stop button. Breakpoints work fine when the test was started from the debug button.
At first I was somewhat skeptical about this approach, but by now it has proven itself being reliable and stable. But, this is a mis-use of a unit test. One of the cornerstones of a test is the possibility to run it in an unattended batch. This test will never complete until a human user takes some action. So, in case you want to try this at home, keep these "tests" well separated from your real tests.