Good bat­tery of tests is like good wine. You will not under­stand its value until you’ve expe­ri­enced it. There’s few things as lib­er­at­ing in soft­ware devel­op­ment as know­ing you can refac­tor fear­lessly hav­ing con­fi­dence your tests will catch any break­ing changes.

I don’t have the time not to write tests

I can’t imag­ine work­ing on Wind­sor if it wasn’t thor­oughly cov­ered by tests. On the other hand, most of the prob­lems I’ve faced on var­i­ous other projects, could have been avoided had they been bet­ter tested. Prob­lem is – they were. Most of the projects I’ve been work­ing on had tests and if you’d inspect code cov­er­age of those tests it would usu­ally yield a rea­son­ably high num­ber. Except code cov­er­age doesn’t tell the full story. What’s impor­tant 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 dif­fer­ent test­ing require­ments from your price cal­cu­lat­ing logic if you’re writ­ing an e-commerce appli­ca­tion. The higher cyclo­matic com­plex­ity and the more crit­i­cal the code is the more atten­tion it requires when test­ing. That’s pretty easy to com­pre­hend and agree with.

There’s another angle to it, which is often over­looked. Indeed, like in the tale of boiled frog, that’s the rea­son why the qual­ity of our tests dete­ri­o­rates – the why of a test. Why and when to write a test is equally impor­tant as what to test. And the answer here is quite sim­ple. So sim­ple in fact, that often over­looked or neglected. When­ever some­thing in the code changes the change ought to be doc­u­mented in test. When­ever your code changes it is most vul­ner­a­ble. 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 cer­tainly am going to make that a rule for myself – any change to a non-trivial code must be accom­pa­nied by a change in exist­ing tests, and (almost always) by addi­tion of new tests.