Big Refactoring Problem

Discussion of testing theory and practice, including methodologies (such as TDD, BDD, DDD, Agile, XP) and software - anything to do with testing goes here. (Formerly "The Testing Side of Development")

Moderator: General Moderators

Post Reply
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Big Refactoring Problem

Post by Ollie Saunders »

Situation:
  • I have a large body of code
  • Said code is desperately in need of refactoring
  • Said code is incomplete and only partially tested.
  • Existing tests are not isolated or independent. One instance of this is where I have three classes OF_TextSmall, OF_TextLarge and OF_Password they each share FOUR abstract classes so those four abstract classes have only tested in the unit test for OF_TextSmall.
Steps I'm taking to alleviate the situation:
  1. Complete all tests so that all functionality overall is tested and fix bugs where necessary. Green bar.
  2. Isolate tests so that I can prove that each and every class has all of the functionality it is supposed to and, where reasonable, none of the functionality it is not supposed to. Green bar.
  3. Piece by piece alter tests to support new refactorings. Red bar.
  4. Carry out refactorings. Green bar.
Problem:
  • If I obey step number two I will likely end up with one hell of a lot of duplicated tests. For instance I would have to change the tests for OF_TextLarge and OF_Password to be equally comprehensive as OF_TextSmall.
  • To update all the tests to prove where code should be refactored would be a big job and I'm likely to miss things.
What I need is a way of modularizing tests so that I can minimize the number of tests that have to be changed.
Does anybody know the name of any (specific if possible) technique I can research to provide a solution to this or have a solution of their own?
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

I generally build a test for each class separately. For abstract classes I create a wrapper that generally does little to nothing if I need to test any methods the abstract class implements itself. Methods shared by classes are tested in the donating class.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

Too consise for me feyd sorry. Please expand. In particular this...
if I need to test any methods the abstract class implements itself. Methods shared by classes are tested in the donating class.
...means nothing to me.

Oh and I just thought of something that could well be the solution to my problem:
Inheritance in unit tests!

Does that still maintain the "keep independent" requirement as it was intended or violate it?
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

Okay, there are two types of abstract classes. Ones that are actually interfaces (they list only abstract methods,) and ones that contain some implementation. The wrapper I create inherits from the abstract class so it can call the implemented methods to make sure they are working. This wrapper only exists inside the testing files. My test creates an instance of the wrapper for the actual testing.

Since those methods are already tested, there shouldn't be a reason to test them again in any other descendants of the class. If there is, your initial tests for the wrapper weren't thorough enough.
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post by Ollie Saunders »

Thanks for the help feyd.
sike
Forum Commoner
Posts: 84
Joined: Wed Aug 02, 2006 8:33 am

Post by sike »

ole wrote: Oh and I just thought of something that could well be the solution to my problem:
Inheritance in unit tests!
yep (:
Post Reply