Respect your test code #3: Make your tests orthogonal

c#, rant, testing 1 Response »
Jun 022009

When two things are orthogonal, it means that the angle between them is 90 degrees – at least in spaces with 3 dimensions or less. So when two vectors are orthogonal, they satisfy the property that there is no way to use the first one to express even the tiniest bit of what the other one expresses.

That is also how we should write our application code: methods and classes should be orthogonal to one another – i.e. no class should try to express what another class already expresses either in part or whole – therefore each class and each method should have only one responsibility, and thus one reason to change.

And test code is real code.

The corollary is that our tests should have only one single reponsibility as well.

That is why I hate tests that look like this:

public void CanRecordPayment()
{
    CreateMortgageDeed(1, new DateTime(2003, 3, 11));
    CreateMortgageDeed(2, new DateTime(2003, 6, 11));
    CreateMortgageDeed(3, new DateTime(2003, 3, 11));
    CreateMortgageDeed(4, new DateTime(2003, 3, 11));
    CreateMortgageDeed(5, new DateTime(2003, 9, 11));
 
    var mortgageDeeds = new DueTermsFinder(new MortgageDeedRepository())
        .FindDueTermsBefore(new DateTime(2003, 4, 1));
 
    Assert.AreEqual(3, mortgageDeeds.Count);
 
    mortgageDeeds = mortgageDeeds.OrderBy(m => m.CaseNo);
 
    Assert.AreEqual(1, mortgageDeeds[0].CaseNo);
    Assert.AreEqual(3, mortgageDeeds[1].CaseNo);
    Assert.AreEqual(4, mortgageDeeds[2].CaseNo);
 
    var result = new TermDebitRecorder()
        .CreateAndRecordTermDebits(mortgageDeeds);
 
    Assert.AreEqual(3, result.RecordedTermDebits.Count);
 
    Assert.AreEqual(new DateTime(2003, 3, 11), result.RecordedTermDebits[0].TermDate);
    Assert.AreEqual(new DateTime(2003, 3, 11), result.RecordedTermDebits[1].TermDate);
    Assert.AreEqual(new DateTime(2003, 3, 11), result.RecordedTermDebits[2].TermDate);
    // .... etc!
}

Notice how this test is actually fairly decently structured – at least that’s what it initiallt looks like… but it actually tests a lot of things: it checks that the output of the DueTermsFinder is what it expects, testing the MortgageDeedRepository indirectly as well – and then it goes on to test the TermDebitRecorder … sigh!

If (when!) one of these classes changes at some point, because the requirements have changed or whatever, the test will break for no good reason. The test should break because you have introduced a bug, not because you made a change in some related functionality.

That is why I usually follow the pattern of AAA: Arrange, Act, Assert. Each test should be divided into discrete steps corresponding to 1) Arranging some data, 2) Triggering a computation or some state change, 3) Asserting that the outcome was what we expected. And if I am feeling idealistic that day, I also follow the principle of putting only one assertion at the end of each test.

I try to never do AAAAA (Arrance, Act, Assert, Act Assert) or AAAAAA, or AAAAAAA which is even worse.

Every test should have only one reason to break.

Respect your test code #2: Create base classes for your test fixtures

asp.net mvc, c#, rant, testing 1 Response »
May 312009

When writing code, I often end up introducing a layer supertype – i.e. a base class with functionality shared by all implementations in that particular layer in my application.

This also holds for my test code – and why shouldn’t it? Test code is as real as real code, so the same rules apply and it should benefit from the same pain killers as we implement in our application code.

For example when testing repositories and services that need to query the database, I can save myself a lot of writing by stuffing all the boring NHibernate push-ups in a DbTestFixture supertype – this includes building a configuration that connects to a test database, building a session factory, storing that session factory somewhere, re-creating the entire database schema in the test fixture setup, and running each test in a transaction that is automatically rolled back at the end of each test + a few convenience methods that allow me to flush the current session etc.

The DbTestFixture might look something like this (note that all my repositories take an instance of ISessionProvider in their ctor – that’s how they obtain the currently ongoing session, which is why I have a TestSessionProvider to inject into repositories under test):

public class DbTestFixture
{
	TestSessionProvider currentSessionProvider;
	ISession currentSession;
	ITransaction currentTransaction;
	bool commit;
 
	[TestFixtureSetUp]
	public void TestFixtureSetUp()
	{
		SessionFactoryHolder.Instance.CreateSchema();
 
		using (currentSession = OpenSession())
		{
			DoTestFixtureSetUp();
			currentSession.Flush();
		}
	}
 
	[SetUp]
	public void SetUp()
	{
		currentSession = OpenSession();
		currentTransaction = currentSession.BeginTransaction();
		currentSessionProvider = new TestSessionProvider(currentSession);
 
		DoSetUp();
 
		currentSession.Flush();
	}
 
	[TearDown]
	public void TearDown()
	{
		DoTearDown();
 
		if (commit)
		{
			currentTransaction.Commit();
		}
		else
		{
			currentTransaction.Rollback();
		}
 
		currentTransaction.Dispose();
		currentSession.Dispose();
	}
 
	protected ISession OpenSession()
	{
		return SessionFactoryHolder.Instance.SessionFactory.OpenSession();
	}
 
	protected ISessionProvider SessionProvider
	{
		get { return currentSessionProvider; }
	}
 
	protected virtual void DoTestFixtureSetUp() { }
	protected virtual void DoSetUp() { }
	protected virtual void DoTearDown() { }
 
	protected ISession CurrentSession
	{
		get { return currentSession; }
	}
 
	protected T Reload<T>(T t) where T : Base
	{
		SaveAndFlushAndClear(t);
		return CurrentSession.Get<T>(t.Id);
	}
 
	protected void SaveAndFlushAndClear(object obj)
	{
		CurrentSession.Save(obj);
		CurrentSession.Flush();
		CurrentSession.Clear();
	}
 
	protected void SaveAndFlush(object obj)
	{
		CurrentSession.Save(obj);
		CurrentSession.Flush();
	}
 
	protected void Save(object obj)
	{
		CurrentSession.Save(obj);
	}
 
	protected void Flush()
	{
		CurrentSession.Flush();
	}
 
	protected void DoNotRollBack()
	{
		commit = true;
	}
 
	protected class TestSessionProvider : ISessionProvider
	{
		readonly ISession currentSession;
 
		public TestSessionProvider(ISession currentSession)
		{
			this.currentSession = currentSession;
		}
 
		public ISession GetCurrentSession()
		{
			return currentSession;
		}
 
		public void Commit()
		{
			throw new System.NotImplementedException();
		}
 
		public void RollBack()
		{
			throw new System.NotImplementedException();
		}
	}
}

Then a fictional repository test might look as simple as this:

[TestFixture]
public class TestMessageRepository : DbTestFixture
{
	MessageRepository repo;
	Guid messageId;
 
	protected override void DoTestFixtureSetUp()
	{
		var message = new Message
		              	{
		              		CreatedAt = new DateTime(2003, 11, 11),
		              		Subject = "some subject",
		              		Body = "some body",
		              	};
 
		CurrentSession.Save(message);
 
		messageId = message.Id;
	}
 
	protected override void DoSetUp()
	{
		repo = new MessageRepository(SessionProvider);
	}
 
	[Test]
	public void CanLoadSingleMessage()
	{
		var message = repo.Find(messageId);
 
		Assert.AreEqual(new DateTime(2003, 11, 11), message.CreatedAt);
		Assert.AreEqual("some subject", message.Subject);
		Assert.AreEqual("some body", message.Body);
	}
}

Note how DbTestFixture flushes in all the right places so I don’t need to worry about that.

This test fixture supertype can be used for all my database access tests, as well as integration testing. But what about unit tests? I am using Rhino Mocks, so my unit test fixture base looks like this:

public class UnitTestFixture
{
	protected readonly MockRepository mocks = new MockRepository();
 
	protected T Stub<T>(params object[] paramsForConstructor) where T : class
	{
		return mocks.Stub<T>(paramsForConstructor);
	}
 
	protected T Mock<T>(params object[] paramsForConstructor) where T : class
	{
		return mocks.DynamicMock<T>(paramsForConstructor);
	}
}

Real simple – it just stores my MockRepository and gives me a few shortcuts to the mocks I care for. Then I inherit this further to ease testing e.g. my ASP.NET MVC controllers like this:

public abstract class ControllerTestFixture<T> : UnitTestFixture where T : Controller
{
	protected T controller;
 
	[SetUp]
	public void SetUp()
	{
		controller = CreateController();
	}
 
	protected abstract T CreateController();
}

As you can see, I make it a real “fixture” – the controllers I am about to test will fit into this fixture like a glove, and I will certainly never forget to instantiate my controller only once, because I start out by implemeting that part in the implementation of the CreateController method.

A controller test might look like this:

 
[TestFixture]
public class TestAuthenticationController : ControllerTestFixture<AuthenticationController>
{
	ISessionContext sessionContext;
	IAuthenticationService authenticationService;
 
	protected override AuthenticationController CreateController()
	{
		sessionContext = mocks.DynamicMock<ISessionContext>();
		authenticationService = mocks.DynamicMock<IAuthenticationService>();
 
		return new AuthenticationController(sessionContext, authenticationService);
	}
 
	// tests down here...
}

Respect your test code #1: Hide object instantiation behind methods with meaningful names

c#, rant, testing 1 Response »
May 292009

One thing, that I find really annoying, is that somehow it seems to be accepted that test code creates instances of this and that like crazy! In a system I am currently maintaining with about 1MLOC where ~40% is test code, I often come across test fixtures with something like 20 individual tests, and each and every one of them creates instances of maybe 5 different entities, builds an object graph, runs some code to be tested, and does some assertions on the result.

This is a super example on how to write brittle and rigid tests, because what happens if the signature of one of the ctors changes? Or the semantics of the object graph? Or [insert way too many ways for the test to break for the wrong reasons here...].

When I come across these tests, I usually factor out the creation of all but the most simple objects behind methods with meaningful names. This has two advantages: 1) It’s more DRY because they can be re-used, and 2) It serves as brilliant documentation. Consider this rather simple assertion that requires a few objects to be in place:

[Test]
public void MortgageDeedKnowsItsActualPrincipalBeforeAmortizationHasBegun()
{
    var deed = new MortgageDeed();
 
    deed.Principal = 100000;
    deed.Amortization.FirstTerm = new DateTime(2003, 3, 11);
 
    deed.Amortization.AddAmortizationStrategyElement(new AnnuityAmortizationStrategyElement
    {
        FirstTerm = 1,
        TermsPerYear = 4,
        PeriodicPayment = 5000,
    });
 
    deed.Amortization.AddInterestStrategyElement(new FixedRateInterestStrategyElement
    {
        FirstTerm = 1,
        Rate = 0.05,
    });
 
    Assert.AreEqual(new DateTime(2003, 3, 11), deed.ActualPrincipalDate);
}

compared to this:

[Test]
public void MortgageDeedKnowsItsActualPrincipalDateBeforeAmortizationHasBegun()
{
    var deed = NewStandardMortgageDeedBeforeAmortization(new DateTime(2003, 3, 11), 100000, 5000);
 
    Assert.AreEqual(new DateTime(2003, 3, 11), deed.ActualPrincipalDate);
}
 
MortgageDeed NewStandardMortgageDeedBeforeAmortization(DateTime firstTerm, decimal principal, decimal periodicPayment)
{
    //...
}

MUCH more clear! The factory method acts as brilliant documentation on which aspects of the test are relevant to the outcome – it is clear, that a mortgage deed which has not yet begun its amortization must report its first term date as the actual principal date.

Go on to test another property of the mortgage deed before amortization:

[Test]
public void MortgageDeedKnowsItsActualPrincipalBeforeAmortizationHasBegun()
{
    var deed = NewStandardMortgageDeedBeforeAmortization(new DateTime(2003, 3, 11), 100000);
 
    Assert.AreEqual(100000, deed.ActualPrincipal);
}

- and we have already saved us from writing 50 lines of brittle rigid test code. Keep factoring out common stuff, so that the ctor of the mortage deed is still only called in one place… e.g. create methods like this:

MortgageDeed NewStandardMortgageDeedWithTransactions(
    DateTime firstTerm, 
    decimal principal, 
    decimal periodicPayment, 
    params Transaction [] transactions)
{
    var deed = NewStandardMortgageDeedBeforeAmortization(firstTerm, principal, periodicPayment);
    Array.ForEach(transactions, t => deed.AddTransaction(t));
}
 
Transaction NewPayment(DateTime paymentDate, decimal amount)
{
    var payment new PaymentTransaction
    {
        Amount = amount,
        PaymentDate = paymentDate,
        ValueDate = paymentDate,
    };
 
    payment.Record();
 
    return payment;
}
 
Transaction NewTermDebit(DateTime termDate, decimal interest, decimal installment)
{
    var termDebit = new TermDebitTransaction
    {
        Interest = interest,
        Installment = installment,
        TermDate = termDate,
    }
 
    termDebit.Record();
 
    return termDebit;
}

which allows me to write cute easy-to-understand tests like this:

[Test]
public void ActualPrincipalDateIsChangedWhenPaymentIsMade()
{
    var deed = NewStandardMortgageDeedWithTransactions(
        new DateTime(2003, 3, 11), 
        100000,
        NewPayment(new DateTime(2003, 6, 11), 5000));
 
    Assert.AreEqual(new DateTime(2003, 6, 11), deed.ActualPrincipalDate);
    Assert.AreEqual(new DateTime(2003, 3, 11), deed.AmortizedPrincipalDate);
}
 
[Test]
public void AmortizedPrincipalDateIsChangedWhenTermDebitIsMade()
{
    var deed = NewStandardMortgageDeedWithTransactions(
        new DateTime(2003, 3, 11), 
        100000,
        NewTermDebit(new DateTime(2003, 6, 11), 4000, 1000));
 
    Assert.AreEqual(new DateTime(2003, 3, 11), deed.ActualPrincipalDate);
    Assert.AreEqual(new DateTime(2003, 6, 11), deed.AmortizedPrincipalDate);
}

This is also a good example on how to avoid writing // bla bla comments all over the place – it’s just not necessary when the methods have sufficiently well-describing names.

Respect your test code

rant, testing Comments Off
May 292009

Sometimes I think it is funny to reminisce a bit about where I was and where I am now. One area where I think I have moved quite a lot, is in regards to testing! And I can’t help to think that part of this “journey” was necessary to learn what I think I have learned, but somehow I still can’t put off the thought that I might have gotten here quicker if someone had told me some basic stuff… therefore, I will try to capture in this post a few points, that I pay attention to when writing tests – in hopes that someone might benefit from a little guidance, and hoping not to be categorized as an old man rambling on about his own percieved experience.

To make it more digestible, I will list some points and show examples on why each point is good where I see fit.

  1. Hide object instantiation behind methods with meaningful names
  2. Create base classes for your test fixtures
  3. Make your tests orthogonal
© 2010 mookid on code Suffusion WordPress theme by Sayontan Sinha