Re: Ambiguous Refactoring Solution

Once upon a time, I had a 600-line C++ class (or two) that I wanted to
refactor. This was before I had automated tests, and I did not have
automated refactoring tools (even today, refactoring tools for C++ are
rather very minimal when compared to those for Java and these tool can be *
buggy*).

So I spent a weekend improving the code.

At some point, I tried manually testing the code. It no longer worked. I
really had no way to determine at what point my changes made the code no
longer work, since I didn't do frequent manual testing of the code while I
was refactoring it. I didn't have Eclipse's history capabilities, or similar
local repository functionality.

So I had to throw away the changed code.

It's not an experience that I would like to repeat.

On Thu, Sep 24, 2009 at 5:41 PM, Adam Sroka <[email protected]> wrote:

>
>
> On Thu, Sep 24, 2009 at 5:24 PM, Richard <[email protected]<legalize%40xmission.com>>
> wrote:
> >
> >
> >
> > In article <[email protected]<2ef359580909241648x5cb1f1d9o599059a169c4f40%40mail.gmail.com>
> >,
> >
> > Adam Sroka <[email protected] <adam.sroka%40gmail.com>> writes:
> >
> > > You repeatedly said "Do you write tests for [some] refactoring?" I do
> > > not write tests for any refactoring. That is not /why/ I write tests.
> > > I write tests to *prove* deterministically, that the code does what I
> > > intend it to do.
> >
> > That's fine for new code development, but the whole context of this
> > discussion is for legacy code, i.e. existing code that has no tests.
> > We then discussed some refactoring choices and then the dogma of "no
> > refactorings without tests!" came out and I raised some examples of
> > scenarios where that dogma just doesn't make any sense. I also raised
> > several examples of where the dogma is sometimes the right advice and
> > sometimes not.
> >
> > I'm only saying that judgment and usefuleness (cost/benefit analysis)
> > trumps dogma.
>
> I agree, on its face, with the argument that judgment can help us to
> determine when writing a test is useful. I object to the strawman
> argument that you are presenting. If I have a huge pile of legacy
> code, and I want to rename a method, do I need comprehensive automated
> tests? Of course not.
>
> However, if I have a huge pile of legacy code, and no automated tests,
> what is renaming a method going to get me? If we go back to the
> original topic of this thread, how is renaming a method going to
> improve the design of a 613 line C++ class?
>
> Call it dogma if you want, it doesn't hurt my feelings, but I'm
> sticking with the assertion that the first, best thing we could do to
> improve that class is to cover it with tests.
>  
>



-- 
C. Keith Ray, IXP Coach, Industrial Logic, Inc.
http://industriallogic.com      866-540-8336 (toll free)
Groove with our Agile Greatest Hits:
http://www.industriallogic.com/elearning/
http://agilesolutionspace.blogspot.com/


[Non-text portions of this message have been removed]



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

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/