Unit Testing My Library

MyLibrary is an example of FreeSoftwareForLibraries

The MyLibrary project has grown so that now just the three main files (MyLibrary.pm, mylibrary.pl, and mylibrary-admin.pl) have grown to over 17,000 lines of Perl.

To help make this code more understandable and easier to modify it is useful to be able to refactor (WhatIsRefactoring) the code, and refactoring depends on the existence of UnitTests. Since refactoring is changing the design of code without changing its function, you need automated tests to make sure that any particular change hasn't affected functionality.

UnitTestingLegacyCode

The problem of retrofitting LegacyCode with UnitTests is addressed by Steve Freeman and Paul Simmons in "Retrofitting unit tests" http://www.xp2003.org/xp2002/atti/Freeman-Simmons--Retrofittingunittests.pdf

"First, retrofitting unit tests is expensive, full coverage can easily take as much effort to write as did the original system without adding any visible functionality. Second, there is an obvious deadlock in that legacy code often needs some refactoring to make it testable, but refactoring should not be undertaken without tests in place to prove that it's safe.

"Both problems must be addressed by a combination of skill and compromise. First, unit tests can be added incrementally, perhaps before changing a component for the first time during subsequent development. Combined with some judicious functional testing, the team can give themselves enough confidence to make progress, although at less than full speed, whilst improving the quality of the code. Second, our experience is that carefully fixing a few "code smells" without unit tests can give the developer enough leverage to bootstrap the writing of a full test suite. As the test suite builds up, the developers should look for opportunities to improve it..."


CategoryTesting


EditText of this page (last edited December 17, 2002) or FindPage with title or text search