What I will be Talking about at Code Camp

As I noted in my last entry, I am a presenter at the  Twin Cities Code Camp, doing a presentation on unit testing.  I thought that I would take a few minutes to discuss what I am going to cover.

I want to spend a little bit of time talking about what unit testing is and particularly what unit testing is not.  The analogy that I use for unit testing is like cleaning up a house.  I typically start in one room and try to get that room clean and then protect it somehow so that I don't track dirt back into that room.  Unit testing is like a fence that I put up to keep bugs out of my code.  The other aspect of unit testing that I find to be very useful is that it is a chance to exercise the "software under test" in ways that the final consumer of that software might exercise the software.  In my experience there is a wealth of new understanding that can come out of the process of trying to write and debug unit tests.

I will talk little bit about whether one should write the tests first or second and my notion that it really doesn't matter as long as you are testing and coding and testing and coding.

The theme of my talk is trying to make unit testing easier under the premise that you are only going to get a finite amount of time to do the testing and anything you can do to make more productive use of that time is a good thing.

I'll demonstrate the NUnit GUI tool.  I'm also going to demonstrate TestDriven.net.  I also will be demonstrating MS test and and MBUnit.  Since this is a Code Camp, I'm going to be showing a lot of code.  But along the way I'm going to do a bit of preaching about how unit testing should be done.

I want to spend a fair amount of time talking about handling of dependencies.  The goal of unit testing is to isolate a small chunk of the software such that you can control the environment of that software to ensure that every possible outcome is exercised.  The classic example would be software that needs to handle various kinds of failure while accessing a database.  If one mocks up the database, it's quite easy to force each of these failure situations to occur every time that you unit test.  I will talk about couple of tools to help you build mocks, NMock2 and RhinoMocks.  We'll also talk about some approaches to building the software that facilitate mocking, and thus facilitate building better software.

Any time that you talk about the development of software, it seems that you must talk about design patterns and re-factoring.  I will not disappoint you.  I have some material on the various design patterns that unit tests follow and how you can re-factor those unit tests to make them easier to use and easier to understand.

I have some material on how it is possible to test the internal aspects of the software from an external assembly, using a sneaky "side door" access process.  Again, lots of code and examples.

I'm not sure exactly how long all of the above will take.  If there is time I will cover a tool that I wrote called XML unit helper.  The intent of the tool is to allow you to write unit tests of XML files.

I am looking forward to this presentation.  It is about a subject, unit testing, but I've spent a lot of time thinking about.  I think it will be a lot of fun to share some of the insights and ideas that I have a unit testing.

tags: unit+testing, Code+Camp, NMock2, RhinoMocks, NUnit, MSTest, XML, dependency+injection