• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Adding unit testing to existing code

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can anyone offer suggestions for retrofitting an exsisting, very large code base with unit tests?
Basically we have an exsisting set of shared code that if we were to sit down and write unit tests for now, it would be a huge undertaking. We now have new managment and new developers who have successfully made unit testing a part of our development process. However now it is expected that all the exsisting code have unit tests writen for them as well.
My suggestion originally was to write tests for classes "when touched" -- if you change the code... you must write a unit test as part of that change. However, the users of the shared code insist that it must all have unit tests. While that would be ideal, it just isn't practical. It would take several months of work, which would then halt any new development. Any suggestions on how to make a case for slowly adding tests to exsisting code without undermining the case for writing tests for all new code? How do you explain that it is ok that this class doesn't have a test, but you MUST write a test for your new code?
Also, after some initial looks at the code, it some of it seems very difficult to go back and write tests for. Is there anyone who has done this and has some words of wisdom to offer?
 
Author
Posts: 55
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


My suggestion originally was to write tests for classes "when touched" -- if you change the code... you must write a unit test as part of that change.


And I think that's a fine suggestion. You might expand on that to ensure that the new unit test covers the whole class being modified instead of just the local change, but the idea of moving forward on an incremental, as-needed basis is dead on.


How do you explain that it is ok that this class doesn't have a test, but you MUST write a test for your new code?


It ain't a perfect world.
Unless there are huge advantages to stopping new development in favor of retrofitting unit tests (maybe due to government regulations, or an impending lawsuit, or something like that), it's probably not cost-effective to do so. So you do the next best thing; approach the problem gradually and incrementally.


Also, after some initial looks at the code, it some of it seems very difficult to go back and write tests for. Is there anyone who has done this and has some words of wisdom to offer?


That's very often the case. Unit testing improves the design of code, period. You realize this once you start comparing the design of code written with and without unit tests.
Now this brings up an additional problem. Do you make the investment to redesign the legacy code while you're adding tests? It may or may not make sense to do that depending on your project. If it's possible to refactor the legacy code gradually, "just to make it easier to test", then that might be the most practical way forward.
[ February 18, 2004: Message edited by: Andy Hunt ]
 
There's a city wid manhunt for this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic