Re: Using refactoring to make code more testable

On Sun, Oct 11, 2009 at 12:36 PM, George Dinwiddie
<[email protected]> wrote:
> [email protected] wrote:
>> Oops ment to save this as a draft. I have largish code base (roughly
>> 10 million lines) that my company deals with and a much smaller code
>> base (roughly 250 thousand lines) my team deals with. Currently there
>> is no unit test coverage of any of the code. And the code was not
>> wrote to be tested. My main task is to get the code covered.  I was
>> wondering what kind of refactoring strategies would help make this
>> goal attainable?
>
> First, read Michael Feathers' book, Working Effectively With Legacy
> Code.  It will help you find or create seams for testing.
>
> Write tests that cover largish chunks of the system as /characterization
> tests/.  These are tests that characterize what the system currently
> does, whether that's right or wrong.  That will let you see when
> something changes, and you can investigate.
>
> Then, as you work on the system, further isolate the part you're
> changing and add more fine-grained tests around that part.  TDD any new
> code you write.
>
> It takes time, but this is a strategy that works.
>

I like the characterization tests approach, and I have seen it work as
well. A variation that I like is to move from programmer focused
characterization tests to ATDD style tests. This works if you can get
your hands on a customer who has a good idea what the system /should/
do. Once you have acceptance tests for important functionality it is
easier to refactor, add unit tests, and start enhancing.

A lot of times with legacy systems the system is the spec. i.e. it has
to do what it currently does and we're not sure what that is. In that
case only characterization tests work.

Other times the system is already unacceptably buggy and the business
knows what it really should do, they just can't afford to replace the
whole thing at once. There are parts that work and parts that need to
change quick. In that case ATDD may be your best friend, because it
allows you to characterize what it /should/ do so that you can drive
in that direction and have some regression coverage for the parts that
already do work.


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/