Tests are your airbag

Good battery of tests is like good wine. You will not understand its value until you’ve experienced it. There’s few things as liberating in software development as knowing you can refactor fearlessly having confidence your tests will catch any breaking changes.

I don’t have the time not to write tests

I can’t imagine working on Windsor if it wasn’t thoroughly covered by tests. On the other hand, most of the problems I’ve faced on various other projects, could have been avoided had they been better tested. Problem is – they were. Most of the projects I’ve been working on had tests and if you’d inspect code coverage of those tests it would usually yield a reasonably high number. Except code coverage doesn’t tell the full story. What’s important is not just that the code is tested. And that’s because not all code is equal.

public class Event : EntityBase
{
	public Event(string title, string @where, DateTime when, string description, UserInfo generatedBy)
	{
		Title = title;
		Where = @where;
		When = when;
		Description = description;
		GeneratedBy = generatedBy;
	}

	public virtual string Title { get; set; }

	public virtual string Where { get; set; }

	public virtual DateTime When { get; set; }

	public virtual string Description { get; set; }

	public virtual UserInfo GeneratedBy { get; set; }
}

The code as above will have different testing requirements from your price calculating logic if you’re writing an e-commerce application. The higher cyclomatic complexity and the more critical the code is the more attention it requires when testing. That’s pretty easy to comprehend and agree with.

There’s another angle to it, which is often overlooked. Indeed, like in the tale of boiled frog, that’s the reason why the quality of our tests deteriorates – the why of a test. Why and when to write a test is equally important as what to test. And the answer here is quite simple. So simple in fact, that often overlooked or neglected. Whenever something in the code changes the change ought to be documented in test. Whenever your code changes it is most vulnerable. And isn’t it he premise of Agile? To embrace the change?

It is not enough to test your new code. If a change to some code is made and no test was changed or added that should raise a red flag for you – I certainly am going to make that a rule for myself – any change to a non-trivial code must be accompanied by a change in existing tests, and (almost always) by addition of new tests.