This will be my last post on unit test lifecycle management. In previous posts, we learned how individual unit tests and test fixtures are run, and how test invocation is affected when test fixtures are derived from an abstract base fixture class. In this installation, we’re going to learn how to manage code that runs before and after groups of test fixtures.

Sometimes, you need some code to run before or after a set of test fixtures. I tend to encounter this scenario frequently with integration and system tests. For example, if you’re using Selenium to run your full system tests through the Selenium Web Driver, you need to make sure that the Selenium server is running before you run any of your tests. You could do this on the build server by extending your build script with a “StartSelenium” task, and then remind all your developers to start the server themselves before they run the tests directly. But wouldn’t it be better to guarantee directly that, every time those ui tests get run, that the selenium server was active? AND, as a bonus, wouldn’t it be great if the selenium server was shut down when the tests finished? Read the rest of this entry »

In my first post in the Unit Testing Best Practices series, I introduced you to the basic lifecycle of an NUnit test fixture. This time, we’re going to see what happens when we give our tests a common test fixture base class.
Why a base class?
There are two cases where having a base test fixture can be useful in keeping your test code simpler:

1. You have lots of the same kind of tests. Maybe you’re writing integration tests for your persistence layer. Your tests are going to all be performing some similar operations, like creating a database connection. Maybe they all need to reference an Inversion of Control container like StructureMap or Autofac in order to retrieve repository instances. You don’t want to write that boilerplate code for every fixture, do you?
2. You have a hierarchy of classes that need testing. If you have a base class in your domain, you will probably want to set up a parallel type hierarchy of test fixtures. In this case, a base test fixture gives you one place to define tests that verify the base class invariants to which all your derived classes need to conform.

The Code

Well, not YOU, of course. YOUR team’s code reviews, I’m sure, are pleasant, productive engagements where everybody leaves feeling good about the results. They happen early and regularly in the development process, the goal of the review is well understood, and you wouldn’t dream of shipping a line of code that hadn’t been through your review process. Your team loves doing them, and you don’t worry about who does the review because you’ve got a consistent standard that your whole team agrees with. You’re just reading this article because there’s this other team in the building that you think would benefit from reading it, and you’re going to forward it to them when you’re done reading.

I’m with you. Personally, I’ve never sat around a meeting table with 15 other developers, Read the rest of this entry »

A long time ago, my development team decided to write our own unit test framework. Today that would be ridiculous, because there are so many mature options from the .NET community (NUnit, MbUnit, xUnit, MsTest, to name a few). But this was 2002, .NET was brand new, and we thought attribute-based metadata was a better approach to describing tests than the interface-and-naming-convention pattern that NUnit required at the time.

Of course, about the same time we’d gotten our homegrown framework running and built a couple thousand tests with it, NUnit 2.0 came out with a brand-new and shiny attribute-based metadata approach. We spent the next 3 years wishing we had the time to port all our tests to NUnit, and stealing features from it for our custom test runner. Read the rest of this entry »