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")
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:
Complete all tests so that all functionality overall is tested and fix bugs where necessary. Green bar.
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.
Piece by piece alter tests to support new refactorings. Red bar.
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?
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.
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.