Re: Ambiguous Refactoring Solution

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/