Re: Ambiguous Refactoring Solution

2009/9/25 Richard <[email protected]>
>
>
>
> Some examples of where judgment comes into play:
>
> - Do you write unit tests for property accessors?

No. I don't use property accessors but public fields if they are just
"dumb accessors".

>
> Without it, you won't have "100% code coverage", but to write tests
> for property accessors that simply return the value of backing store
> is silly.
>
> For property accessors that have dynamic lookup behavior or produce
> computed properties it would make sense.
>
> There is no dogmatic answer to the question, only one which applies
> judgment in context.
>
> - Do you write unit tests for the Rename refactoring?

No, since I work in C#/Visual Studio and the Rename refactoring tool
makes sure I'm not changing the behaviour of the program.

>
> I could modify an existing test on the existing method by changing the
> name of the method there and get a "failing" test which I can correct
> by performing the rename. However, its generally a fruitless
> exercise.
>
> If I apply Rename through an automated method that updates all the
> references, production code and unit tests combined, in a single
> sweep, then is there a need to write a unit test for this refactoring?
>
> I say no, its a waste of time.
>
> If I have an automated and reliable Rename mechanism from my
> development environment, its even more fruitless to try and make a
> failing test for the new name because now I've made one name change
> manually and the other I'll be making automatically. Its going to be
> more reliable to make allt he name changes automatically in a single
> change than to make two separate changes. Furthermore, in a language
> without reflection like C++ I can't even get a "failing" test for the
> missing name, I can only get a test that doesn't compile.
>
> - Do you write unit tests for automated refactorings?

Nope. I think this is the culprit of the discussion - the distinction
between automated refactoring and manual refactoring.

When Adam and others, including me, use the word 'refactoring' we
generally mean manual refactoring, not automated refactoring.

>
> If I invoke Extract Method in my IDE, what purpose does it serve to
> write a unit test for that? Yes, I could enhnace my code coverage by
> covering the extracted method and sometimes that is the desired goal
> because I'm going to change the behavior in the extracted method (bug
> fix, for example) and the failing test covers the newly desired
> behavior and I make the test pass by adjusting the extracted method.
>
> But suppose I'm doing a series of automated Extract Method
> refactorings in the context of doing Compose Method on a very large
> method or function. In this case, the point of the refactorings is to
> introduce semantic clarity to the large method. How do I write a
> failing test that says "semantic clarity is not present" in the
> source for the original long method? Maybe you can contort that into
> some sort of meaningful test, but I consider it another fruitless
> exercise.
>
> There is no dogmatic answer to the question, only one which applies
> judgment in context.
>
> --
> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
> <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
>
> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
> 


--
twitter.com/olofb
olofb.wordpress.com
olofb.wordpress.com/tag/english


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

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/