TestCase is one way you can run parameterized tests with NUnit. An example of how this is useful is testing a whitelist or blacklist. You only need to write the test once, then pass in your items to test some sort of output. If the requirements change and words need to be added to or removed from your list, you simply add another entry without the need for writing another test or set of tests.

I’ve found myself using TestCase (formerly RowTest) more and more often. If you see lots of very similar tests that shared assertions, or test method names with numbers/values in them, these are signs that you might be wanting to use TestCase. Let’s take a look at the following examples. 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 »

Do you find yourself writing the same methods over and over in different classes? Say your project needs both a “Dog” class and a “Cat” class — do you end up writing a “sleep” method for both? What if, in two months, the client needs you to add a “possum” to the system? Do you end up going in and retyping “sleep” instructions yet again? When you’re modeling a system with many similar parts, it takes way too much time and effort to keep duplicating code for each class. Imagine how hard it would be to maintain a large project with thousands of classes! Besides, it violates the DRY principle of good programming: Don’t Repeat Yourself! There must be a better way. Read the rest of this entry »