Just Go Ahead and Write the Test

07.05.2012 23:37 by kbeckman | Comments

Recently, I’ve found myself in a couple of rework or debug situations where I’ve really wished that I had taken a few extra minutes and written a test or two to prove the code in question actually worked at one time… Both situations were outside of what I would consider the “normal” day-to-day unit testing scenarios where I’m covering typical model or controller logic. One situation involved dynamic routes created by OmniAuth and the other involved a local Git submodule for a gem I’m working on.

 

Adding the route tests was an easy fix, but it took me a couple days worth of recommitting the same submodule pointer updates in our base repo before I finally got sick enough of re-doing it. It helped to finally figure out why it kept happening too… One of the other devs on the team had re-cloned the project repo and forgot to do the submodule init/update steps. Every time I would commit, I would update the submodule commit pointer. Every time he would commit, it would roll the commit pointer back to a previous version. One RSpec test put an end to all of the commit games…

 

require 'spec_helper'

describe "Git Development Submodule" do

  it 'should have the latest commit id' do
    submodule_status = `git submodule status`
    error_msg        = 'Solution: git submodule update && git submodule init"

    # Ensuring the [git submodule status] command actually produces a result...
    # TeamCity tests are run under a build agent where source code is copied to rather than updated/fetched in a git
    # repo. This is a local dev machine test only...
    if status_msg.present?
      status_msg.should include '24a1c1299....', error_msg
    end
  end

end
  • Just shell-out using the git submodule statuscommand which returns the current submodule commit ID.
  • Notice the check for a status message before checking the commit ID. Depending on your build server configuration, you may not get a value for this when running in a CI scenario…

In Case Your Compiler Decides to Take the Day Off…

02.19.2011 06:24 by kbeckman | Comments

The following is noteworthy because this is the type of unit test a conscious developer would write if their C# compiler occasionally takes the day off…

 

public interface IMyInterface
{
    void MethodThatDoesntMatter();
}

public class MyClass : IMyInterface 
{ 
    public void MethodThatDoesntMatter() { return; }
}

 

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Test.WastingYourTime
{
    [TestClass]
    public class MyClassTest 
    {
        [TestMethod]
        public void ImplementsIocInterface()
        {
            Type interfaceType = typeof(IMyInterface);
            Type concreteType  = typeof(MyClass);

            Assert.IsTrue(interfaceType.IsAssignableFrom(concreteType));
        }
    }
}

 

The problem is… Unlike the developer who wrote this unit test, the C# compiler doesn’t take days off. The .NET compiler also doesn’t waste valuable development time with senseless Internet browsing or BBQ recipe research. Just because you can test that a class implements a certain interface doesn’t mean you should waste your time doing so.