Re: Ambiguous Refactoring Solution

Richard:

I think you may be misunderstanding what I mean when I say to cover
with tests before you refactor. I don't mean that you write a failing
test to drive the refactoring. I mean that you have an already passing
test that should continue to pass after you refactor. That gives you
confidence that your change preserved the intended behavior. I assumed
that you were familiar with TDD enough to understand, "Red, Green,
Refactor." But, I should have been more clear.

There are a number of schools of thought on property accessors. It is
generally true that they don't need to be tested directly.

On the other hand, you could get into trouble with certain frameworks
in e.g. Java where properties are modified through reflection using a
name that is stored in a property file, XML file, or String (e.g.
Struts, Spring, Hibernate, numerous others though this practice is
starting to fade in favor of Annotations.) If you change the name
those things could break, even with an automated refactoring tool. It
would be nice if there were /some/ test somewhere that failed before I
pushed that into production.

Personally, I come from the school that says that if all I am going to
do is access a field I should just make that field public until I have
a reason to encapsulate it. Once I have a reason, that probably
implies that I need a test. YMMV.


On Thu, Sep 24, 2009 at 3:38 PM, Richard <[email protected]> wrote:
>
>
>
> Some examples of where judgment comes into play:
>
> - Do you write unit tests for property 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?
>
> 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?
>
> 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>
> 


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

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/