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.


Shaun Wilde says:

I agree… Tests for code coverage sake are bad IMO and you tend to find these tests when they have been written after the fact rather than alongside the code being developed.

Daniel Lidström says:

My tests have two purposes: aid in design and as a specification. A change to existing code should come with a new specification, thus requiring a new test. This is BDD, “TDD done right” as some people have called it. I sometimes try to get this point into my coworkers mindset, although it seems they can’t really grasp it, unfortunately. At least they are unable/unwilling to apply BDD. This is one of the big problems in our industry, in my opinion.

[…] being done changed, and was updated everywhere except for the website (this also reinforces the point I made in my previous blogpost, that changes in application code should almost always be accompanied by changes to tests). So the […]