Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Backing in Unit Tests into an existing project

Recently I was asked about backing in unit tests into an existing project.  In particular I was asked A) was possible and B) is it worth it.  In short my answers to both these are Yes and Yes.  However, backing in unit tests is not without its challenges.  I thought today I would go express my experiences with doing exactly this and what types of hurdles I ran into.

Start off by only testing new code
When backing in tests, it is very important to accept the fact that a large percentage of your application is going to be untested.  Accepting this fact will help you move forward.  I would suggest that as you write new code (be it new modules, features or whatever) you write them following the TDD practice.  This will be the simplest way to get the ball rolling. 

Doing this is also an easy way to get other team members on board with the testing idea.  I know from personal experience that when we wanted to started following TDD on a project that was 2 years in, many of the other developers thought it was a waste because we have so much that is untested.  They thought it would take too much time/effort to write test for existing code.  I agree with this.  So only test going forward

Add tests to existing code only when changes are needed
I know I just said above to only test new code, and this is true.  However, when you are making changes to existing code test those changes.  Again, you don't have to try to test all the existing code, only the path ways you are adding/changing. 

If you follow this, over time you will start to build a nice suite of tests that tests not only new code, but some existing code as well.

Mock as much as possible
Mocking is a great tool.  I like to mock code that I don't have control over, or when I have no faith the code will work reliably.  This is especially important in a project that does not have tests. 

An example would be this.  Lets say you are adding a new feature to an application that needs to call into some sort of calculation engine.  Since this calculation engine is not tested and you have no real faith that it will work reliably, mock it.   You should know that given a valid set of inputs you expect to receive a given response.  By mocking this you remove all risk of the calculation engine failing thus causing your tests to fail. 

*** I can hear you now, you want your test to fail when the calculation engine fails.... No you don't.  Unless your test is actually testing the calculation engine, you don't care if it passes or fails.  You just need to call it. ***

Take this as a learning experience
Take this time as a way to learn to write good solid tests.  This will be of great benefit later in your next project.  Also, you will also learn how to write better code that is more acceptable to testing (hum... sounds like another good post).  Remember, in order to become good at something you must first be bad at it.  But with practice you will become better and you will be a better developer because of it.

Be patient
Testing is painful at first.  It is a shift in your development mind set.  Be patient, it gets better.  This is no different then learning anything else.  It will take time, but eventually you will become comfortable with TDD and it will become second nature.  You never know, you may end up like me and find it odd when you are NOT writing tests.

I hope this helps.

Till next time,


Posted 10-09-2007 7:35 AM by Derik Whittaker

[Advertisement]

Comments

Jan Van Ryswyck wrote re: Backing in Unit Tests into an existing project
on 10-09-2007 2:27 PM

I'm currently reading "Working effectively with Legacy Code" by Michael Feathers. He describes the exact same thing: start with testing the new code and put the existing code that you change in a test harness (using mocking dependencies along the way). Great post.

DotNetKicks.com wrote Backing in Unit Tests into an existing project
on 10-09-2007 2:30 PM

You've been kicked (a good thing) - Trackback from DotNetKicks.com

Derik Whittaker wrote re: Backing in Unit Tests into an existing project
on 10-09-2007 2:37 PM

@Jan,

I think i may need to grab that book and give it a read.

anonymous wrote re: Backing in Unit Tests into an existing project
on 10-27-2007 2:00 AM

Excellent post.  There are too many developers out there that are lazy in that they don't care to understand the WHY codeing code to test code may be a thing worth doing.  Even if they have done some, maybe they really didn't do it right, or do enough to fully understand its benefits.

Examples of why certainly are  helpful to those who have not dived into a lot of Unit Testing or may have the wrong iterpretation of it because they simply don't understand it well enough or were in a place that really didn't have standards to do it right and within certain limits that you speak about.

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)