Using inheritance in your tests

In my previous post I described the new structure of my test code, but what happens if you have multiple tests that you need to write that use the same setup code, but with a slight difference. For example lets say that in my setup code I am setting up a call to a service to send out email notifications. In all instances I would expect that this service would be called; however I have a new test where I would like to use that same basic setup code but I would like to test the negative behavior (ie that emails are not sent out based on a condition).

When this presents itself what I do is is the following:

1. Create a new folder in Visual Studio named the same as your namespace
2. Extract the tests from the class file into another class file.
3. Name the new class file the same as the test name
4. Inherit from the base class file (ie the class file we removed the tests from)
5. Create a virtual void method in the base class named observe()
6. Call the virtual method at the end of the Setup method in the base class
7. Create an override method in the sub-class to set the conditions that would exercise the expected behavior
8. Name the new Test method in the sub-class execute()
9. Place all class files into the new folder

The downside of this approach is that you end up with quite a few test class files because you end up with one test per class. I am ok with this because I can look at my test names and easily determine what they are visually in Visual Studio.

The upside is I can easily group me tests together and reuse setup code across multiple tests.

My new way of writing tests

After my experience at the TDD Firestarter event in Tampa, FL I changed the way I write tests. Before this event I would write tests that would verify an expectation. This would manifest itself in the name of the test method as verify_that_the_result_of_x_equals_the_expected_value. When I left the TDD Firestarter event my tests looked a little more like context specifications. Below is a sample template of what a class file structure would look like in the new form.

namespace spec_for_message_processor
{
    [TestFixture]
    public class when_the_message_processor_processes_a_valid_message {

         [Setup]
         public void context() {
         }

         [Test]
         public void should_call_the_packager_to_package_artifacts() {
         }
     }
}

Let's look at this structure and pick it apart a little.

1. The namespace reflects the spec for what we are testing. This could be a class or a module where we need to test the interactions and the behavior of that class or module.
2. The name of the class uses then when x happens wording. This wording places context around what you are testing.
3. The name of the method states what should happen based on the context, so in this example when the message processor processes a valid message then it should call a packager to package some artifacts.

This approach reads well from top to bottom and it makes it easier in my opinion to understand what the intent and purpose of the code is. In my next blog post I will discuss using inheritance in my tests and how that changes what we have written here.

An Experiment in Pair Programming

I decided to run an experiment at work to block out an hour a day and publish a request for anyone to pair program with me during that hour. The environment that I work in is not very progressive in terms of TDD (Test Driven Development) and XP (Extreme Programming). In other words people are set in their ways a bit and not very aggressive in terms of learning new ways of doing things in my view. I thought it would be a good idea to share some things I have learned with my co-workers and what better way than to pair program.

The purpose of this Blog post is to catalog my experiences during this experiment. To be honest I have not ever worked in an XP environment, so this process is a bit new to me also.

Day 1

On the first day I had three people show up to pair with me. I had only asked for one person and that it was first come first serve, but I am not going to turn people away, so what we did was we discussed the project that I was working on and we walked through the code a bit.

I thought this went well; however it made me think that what I should do in the future is post a wiki entry that would explain what we would be working on that day. This way people had the opportunity to come prepared to write code. As I move through this experiment I am sure I will learn a ton.