Category Archives: Unit Testing

Heartland Developers Conference – Day 1

1 Reply

The first day of the HDC is over, and it started out awesome! I got in Wednesday afternoon and was invited out to dinner with a few really talented individuals. I had a great chat with Mike Benkovich over his recent MSDN Events in Des Moines, my interest in Microsoft’s Team System, and the recent Bears vs. Vikings game.

The first day of sessions did not disappoint. Ron Jacobs started off with a great keynote over using TDD jointly with the MVP pattern to make both testable and loosely-coupled solutions. I then sat in on sessions over practical TDD usage; an overview of Visual Studio Team System; an introduction to the movement that is ALT.NET; and some practical tips on effectively refactoring database schemas.

I will admit I’m impress with how much more focus is being put on agile development and TDD in particular this year. I think almost every session I attended today had some mention or discussion on writing unit tests for your code. Last year, there was only one session over TDD and it was extremely 101-type material. I’m glad to see more presenters mentioning TDD and agility in their talks.

Oh, how times are a-changin’.

Changing of the Mock Tool

1 Reply

I’ve just recently started using NMock2 on a new class library that I am building, which makes use of several external resources (e.g. mail server, FTP, etc.). So, in writing my unit tests, it made sense to use some type of mock object so that I was not dependent on these external resources during testing.

However, because my assembly is strongly-named, I discovered that I can’t use the NMock2 library because a strongly-named assembly can only reference other strongly-named assemblies – and for some reason, NMock2 is not strongly-named. There have been a couple requests, but they all seem to have fallen on deaf ears – or nobody is at the wheel steering this project anymore.

So I am left looking for other options. I thought I’d give Rhino Mocks a try after hearing about it from Tim. It looks promising…

Tips for Effective Unit Testing

Leave a reply

I can see a lot of benefits for practicing TDD when developing software applications. But writing Unit Tests can be a lengthy process when done effectively, and it can be difficult justifying the time spent, especially to managers or clients.

So, here are a few tips I’ve learned from my own experience:

  • Do not test Getter/Setter properties. For the most part, getting and setting properties is a trivial matter. In the instances where complex logic is implemented in the property, you can usually still get away with not explicitly testing them. Or, test them via another unit test that verifies some business rules.
  • Remember good OO Design. If you are not using good OO design, your unit tests will be pretty difficult to write and maintain. Just as small changes in a highly-coupled system can break other parts of the system, the same can be said of your unit tests.
  • Do not test for the sake of testing. Although some may argue, I don’t find it necessary to write tests for every class in my project. Unit tests are intended to treat your classes or projects as a black box. The test gives an input, receive an output, and tests it to see if the expected value is equal to the actual value. Therefore, it is possible to write unit tests primarily for controller classes, and test the business classes implicitly.

If you know any other tips for writing effective unit tests, feel free to post a comment and share your experiences.