NetDug Unit Testing

So last night I had the opportunity to be the moderator at NetDug, we were talking about Unit Testing.? It was very interesting.? We had one of those nice mixes between people who had not done unit testing yet, to guys who knew way more about it than I do.? I went into the talk with 20 slides, I think I showed about 5 of them.? I consider that a success (I threatened the audience, the less they talked, the more slides I would show).

Slides and sample code

What I learned from last night:

1. I’m not much of a moderator (I talk to much)
2. Code coverage is a art in divination
3. Mock/Stub/Fake Objects are hard to explain
4. Over use Mocks could be a code smell
5. The discussion format actually works pretty well for talking about unit testing
6. If you give geeks a chance to talk, they will talk

What I hope everyone else got from the topic:

1. Unit testing forces you to write better code
2. Unit testing forces you to use better object oriented principles

Test Technology

This was an early question, what technologies to use to test your code.? NUnit, MSUnit, and MBUnit were all mentioned and viable, and stable, technologies.? For mock objects (which you are going to need) there is Rhino Mocks and TypeMock.? I suggest Rhino Mocks over TypeMock for anyone who can’t purchase the full version of TypeMock (but there is a nice free version as well).

Then there are the helper technologies: TestDriven.Net and ReSharper are the main two, but apparently MSUnit’s runner isn’t bad either (I haven’t used it yet).? All of these tools make it easier to run your unit tests from inside Visual Studio, and each has other benefits.? TestDriven.Net has wonderful Reflector integration (a better object browser), and ReSharper…ReSharper is just a must have (that is me talking, not the group).

Code Coverage

Code Coverage, using tools like NCover (free version), tell you how much of your code base is tested.? This was one of the early questions.? How much of your code base should be tested?? Answer: it depends on the product.? My view is that a library (no UI element) should have +90% coverage, if there is a substantial amount of UI then the project can get down to 60%.? If your code coverage gets below that you just aren’t trying, or you need to rethink your architecture.?

I did talk a bit about code that was not really testable (not in an automated way anyway): UI, Database code, and external resource code are all potentially untestable.? More on this in a moment.

Database code is not testable if you can’t return the database to a known state (you can restore the database data).?

UI code testing should be avoided because UI tests have to be so bound to the UI that they are brittle.? So you end up spending a considerable portion of your development time fixing broken test. Brittle tests are to be avoided whenever possible.

Testing existing code

Probably the hardest question to answer from last night was: how do you test existing code bases.? And that came up over and over.? Do you start with integration tests and then work in unit tests, or the other way around.?

I will admit, most of the time when I talk about unit testing, I center it around new projects.? Unit test is hard enough with new code, testing old code that wasn’t written with unit test in mind is a migraine waiting to happen.

The audience did have some good advice though.? Pick parts of the project that you need to work on (say one class) and make that testable and tested.? Essentially you start creating silos of tested code.? The other suggestion (and I actually had a slide for this) was to get the book: Working Effectively with Legacy Code.? Finally, buy TypeMock — the big boy version, not the free-be version.? You’ll need it.

UI Testing

This is my treatise on writing unit tests for the User Interface:

1. Don’t do it until you are done with the UI.
2. Only test that the UI works in a basic sense.
3. You still have to test the UI by hand.

If you start writing UI tests while you are developing the UI, you will continually break the tests.? Writing the test by hand is none trivial, and using tools to write them is also error prone.? Finally, these tests can’t tell you if the UI is just bad.? Only exposure can tell you that.? Every developer should be forced to have to use their UI repeatedly so they know where is sucks.? You wont get that with automated UI tests.

That said, there are tools to help you test web user interfaces. Watin, Watir, and Selenium are all there to help.? We shall see if Team Systems adds anything to help with this (I’m hoping it does).

Testing Database code

This is essentially, testing code that touches the database.? Could be your NHibernate code, could be a stored procedure, could be ADO.Net code.? But really, this is just code that must touch an outside resource (database, file system, serial connection, etc) and there is no way, or point, to abstract it out any further.

The main point here was to have a way to get the data back to a known state.? Without that everything else gets much harder.

We also came up with a new term: SQL Ejaculation.? That is a pattern smell where an excessive amount of your HTML comes from you SQL database.? Like the entire site.? All of the HTML.? And you have stored procedures that simply build the HTML — in a 10,000 line stored procedure.? That is SQL Ejaculation.

Note: if this comes up in a Google search I might get worried.

After the meeting

We all went to Table Rock for a beer.? ‘nuf said, it is a great group.

Finally, to the guy who asked me a question after the meeting was over: I’m sorry, I just haven’t had to draw multiple, overlapping, transparent images on a win form using GDI.Net in a really long time.? I know it involves alpha-transparency values, but I haven’t done that in years.? Maybe you should look at WPF.