I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Adding Unit Tests to Legacy Projects

06.29.2010
| 5280 views |
  • submit to reddit

While test driven development is widely accepted to be the best way to ensure quality in your project, not all projects start with this intention. In fact, some projects that you inherit may have no tests at all. These are the problem projects - you have a load of unfamiliar code in a legacy project that you're working on, and no tests. What's the best way to approach this?

The best suggestion that I have heard around this is fairly obvious, but it's worth repeating. As you add new features, functionality or bug fixes, make sure to write a unit test so that you can capture the state of the system before you add in your code. With a bug fix, you want to have a failing unit test setup; with additional functionality you'll want to ensure that you haven't broken anything after adding your changes. This incremental approach will eventually lead to you having more complete test coverage for your legacy application. 

Perhaps it's better to look at some key areas and think about writing up more complete test suites for those areas. How can we identify key areas? They would be: 

  • Parts of the code that get most 'traffic' from users / key use cases
  • Parts of code that have had a lot of bugs logged against it
  • And the biggest giveaway, critical code that looks complicated to you.
With experience, you get a gut feeling about the code that needs more testing.

These are just two of my approaches to adding a good test suite to your code. What are your suggestions for dealing with these zero-test projects? 

(JUnit is the most commonly used testing framework for Java applications, built into all the major IDEs. For those of you who have read this article, and are unsure about what to see what the basic JUnit test setup looks like, here's a really quick overview. DZone also provide this great refcard on JUnit & EasyMock. Also, if you're considering test driven development, I'd recommend the following cheat sheet[pdf].)

Tags:

Comments

Michael Kebe replied on Tue, 2010/06/29 - 5:36am

If you are looking for further readings. Try the excellent book by Michael Feathers: Working effectively with legacy code.

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/ref=sr_1_1?ie=UTF8&s=books&qid=1277807759&sr=8-1

Jeroen Peelaerts replied on Tue, 2010/06/29 - 8:05am

There are other ways and better ways to determine which parts of the legacy code should be tested using some simple metrics. A practical approach can be found on our blog.

http://www.software-fundamentals.com/?p=34

Grtz,

 

Jeroen.

 

Artur Biesiadowski replied on Tue, 2010/06/29 - 9:07am

In my experience, finding a place which should be tested is a smaller issue. Bigger problem is often how to test something which was not designed to be working/tested in separation from the rest of application. Refactoring is kind of an answer, but how do you test if refactoring itself has not broken something subtle...

 

James Sugrue replied on Tue, 2010/06/29 - 9:46am in response to: Artur Biesiadowski

Excellent points. The refactoring of code into something testable can be a huge issue.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.