Test-Driven Development and me: NUnit vs. MSTest

We’re at a point in our development where I work that we’re re-evaluating our continuous integration process. Of course, like any good development group, this means thinking about our unit/integration testing.

When I first joined this team, there really weren’t any good tests. There were a few tests that were doing things like testing setters and getters on various object properties, but most methods had no test coverage whatsoever. So, I dumped the property tests and had my team get to work implementing what we called “unit tests” but what actually ended up being integration tests. These tests would hit endpoints of our API’s and make sure the output was as expected. This was partially due to expediency, i.e. getting something in place so that we could have a battery of tests to run before we did check-ins. It was also partially due to wanting to avoid an onerous collection of tests that we spent more time maintaining than our actual code. Our architect has been down that road with past companies he’s worked for, so we were strongly cautioned against having a huge convoluted unit test base.

Anyway, now that we’re trying to flesh out our continuing integration process, I’m taking the opportunity to really re-evaluate our testing infrastructure and patterns. A big part of that is going to be researching NUnit and seeing if we want to use that instead of Microsoft’s testing framework. I should probably mention at this point that we are doing mainly C# development. I also want to have a solution that doesn’t require re-engineering our codebase. That is a challenge as well as most mock object frameworks really only work well with dependency injection everywhere. And we don’t do dependency injection. So, we’ll see what shakes out.