Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

I am participating on the development of the web application which has several years of history behind it and there never was enough value and effort put on refactoring, so considerable part of the code base of this application really deserves to be marked as legacy.

As the work with the code base becomes tedious and a lot of these problems are acknowledged but are not being dealt with, people start to push forward unit testing as a possible remedy that would enforce better maintainable code.

Only a few members of the development team have some actual understanding of unit tests let alone experience with unit testing. Nevertheless these people are starting with unit testing on parts of the new code which is being written. These unit tests should become an example for other members of the development team and also a proof of value of unit testing to management and stakeholders. This way we would like to present unit testing to our colleagues in the best possible light and avoid the fail, which would most probably mean and of all the unit testing efforts.

Therefore the question:

Are there some well known nasty pitfalls to try to avoid at all costs when starting with unit testing on a partly legacy (web) application?

share|improve this question
add comment

1 Answer 1

up vote 3 down vote accepted

I'm not sure whether or not these qualify as "well known", but they certainly qualify as "nasty" (and apply to any kind of application):

  • Global gobs: heavy reliance on global values for information, making it difficult to tell what modifies which variable where.
  • Ball of spaghetti: everything is closely related to everything else, and when you change something in one place it does horrible and weird things to something you'd swear was completely unrelated.
  • Breakout blues: You want to take something and put it into a unit-testable framework, but to do it you've got to break a chunk of code out of where it is and put it into an object or some other test-friendly structure. Also occurs where you're trying to send information to your new code but there's no sensible way to get it there without rewriting the legacy work. Usually occurs with ball of spaghetti and global gobs.
  • We don't need no steenking objects!: Old code written and designed by people who had never heard of object-oriented design, and would have thought it was for wusses anyway.

On a more serious note, you actually will get your best results from unit tests around new code the next time anything needs to be done with that code: the tests will tell you immediately if there's a problem with the changes. The end result is that the unit-tested code becomes the most stable and bug-free code in the system, but it does take some time for this to become obvious.

I'd recommend you have a list of the problem areas of the application so you can point out that new problems aren't happening in the unit-tested code when you're trying to argue for increasing the amount of the application covered by unit tests.

The other big thing you're going to need to push for is first modularizing then adding unit tests to the old code. Effectively, you'll need a process where any time anyone needs to do anything to the legacy code, they are expected to refactor it in such a way that unit tests can be easily added to it, and add those tests. That will gradually clean up the problems with the old code with a relatively limited impact - but it will also take a long time (exactly how long depends on how big the application is, and how intertangled it is).

Good luck!

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.