Testing

Unit Testing Events And Callbacks In C#

The Problem

When you want to unit test a method it’s usually pretty simple. Call the method, pass it it’s parameters and assert against it’s return value, or some other property of the object that may have changed.

What happens when a method doesn’t return a value, or update some property? What happens when it leads (perhaps after some delay) to an event firing, or a callback getting called?

Events firing and callbacks getting called are very similar, but subtly different, so I’ll cover them both.

Continue reading

Legacy Code Katas

I like Kata’s, I’ve get a lot out of them, but if I’m truly honest, they don’t really address one area of programming where I think I need practice, and that is in working with Legacy Code. In pondering this problem I came to the conclusion that I need a way of doing deliberate practice for legacy code work, and some variation of the Kata idea seems like it might work.

Continue reading

The Anagrams Kata

The following is my C# implementation of the Anagrams Kata as described on cyber-dojo.com

Write a program to generate all potential anagrams of an input string.

For example, the potential anagrams of “biro” are

biro bior brio broi boir bori
ibro ibor irbo irob iobr iorb
rbio rboi ribo riob roib robi
obir obri oibr oirb orbi orib

Let’s write a test.

[Test]
public void NoCharacters()
{
    var expected = new List<string> {""};
    Assert.That(Anagrams.Of(""), Is.EqualTo(expected));
}

As is almost always the case, we start with the degenerate case of an empty string. We don’t do this solely to ensure the degenerate case is handled (that’s part of it), but with this first test we’re thinking about the API of our new code.

Continue reading

Are Unit Tests the new Comments?

It’s verging on heresy to even talk of Unit Tests and Comments as being in any way related. They serve different purposes, work in different ways, and have nothing in common.

Except

Comments

• Document Interfaces, API’s etc.
• Can drive development by writing pseudo code comments first.
• Mark outstanding work using TODO comments.
• Explain particularly complicated pieces of code.
• Context to help future developers avoid breaking the code.
• Document expectations, side-effects etc.
• Can get out of sync with the code.

Unit Tests

• Document Interfaces, API’s etc.
• Can drive development by writing tests first.
• Mark outstanding work using failing tests.
• Help tease out particularly complicated algorithms.
• Tell future developers when they’ve broken the code.
• Test expectations, side-effects etc.
• Likely to fail if out of sync with the code.

OK, I’m using a little bit of poetic license here to highlight the similarities. You can find a handful of similarities between almost anything if you look hard enough. Nonetheless, there are similarities. Automated tests solve many problems that comments have used to tackle.

Continue reading

Fluent Mocking

Here’s a scenario (for once not a hypothetical scenario, this is a real system I worked on). I was building a wizard based app. To be more accurate I was building lots of wizard based apps.

After a couple of wizards the functionality became clear and I extracted it to it’s own framework. My apps could then focus on actual bread and butter functionality.

Two of the objects in my framework are ‘Wizard’ and ‘WizardStep’. A Wizard contains WizardSteps. You get the idea.

Continue reading

Retrofitting Tests To Legacy Code

One problem with TDD is that those who try it, often begin by writing a few trivial tests to get the lie of the land. Then instead of using TDD to write new code they do something much much harder.

They do what I did, they start out by trying to write some unit tests for existing code. Either a past project, or more likely the project they are currently working on. Then they discover that these projects are almost impossible to test.

Continue reading