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.


Posted 02-27-2011 12:22 PM by Krzysztof Koźmic

[Advertisement]

Comments

Vitaly Stakhov wrote re: Tests are your airbag
on 02-27-2011 1:16 PM

I don't think changing tests on each code change is always a good thing. A change to a class can be refactoring on a level higher (on a feature level) in which case I would like to have a higher level test remaining the same and verifying the code still works as it's expected to. Otherwise do the tests really test the code if they change any time the code changes?

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)