Page 1 of 1

Big Refactoring Problem

Posted: Mon Sep 18, 2006 5:37 pm
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?

Posted: Mon Sep 18, 2006 5:56 pm
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.

Posted: Mon Sep 18, 2006 6:03 pm
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?

Posted: Mon Sep 18, 2006 6:19 pm
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.

Posted: Mon Sep 18, 2006 6:34 pm
by Ollie Saunders
Thanks for the help feyd.

Posted: Tue Sep 19, 2006 2:23 am
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 (: