William C. Wake's Blog

May 2004 Archives

Refactorings require new tests

Someone asked on the XP egroup about getting access to private methods for testing purposes. Others suggested a number of ways to get this effect, but it got me thinking about refactoring.

Refactoring is often thought of as a pure, safe transformation: convert a program into another program with the same semantics but a better design. From the standpoint of a refactoring tool, the "same semantics" part is crucial.

But refactoring also has a psychological side: a better design, but also a different design. A different design may induce people to act differently (indeed, that's why we do it!). In particular, a different design may give people different expectations about code.

Following are some examples. In each case, I'll assume the code was created by test-driven development, and adequately tested before the refactoring.

• Extract Method - the code worked as part of another method (and still does). But now, the reader's going to assume they can call this method from other parts of the class. Is the extracted method tested sufficiently on its own terms?
• Expose Method (private becomes protected) - now, subclasses expect to be able to call this method (either directly or via a call to super()). We'll need to create testing subclasses to verify that it works in that context.
• Expose Method (to ) - Other objects are free to call it. The original object no longer has control over the order in which this method is called. (We may have had a method that was only to be called if another method was called first; when it was private, we were ok; if we expose that method, it's hard to enforce this obligation.)
• Extract Class - The object now stands alone. Is there a test class testing this object by itself? You may need to extract a new test class, but you also may find you need new tests to cover everything.

Scratch Refactoring

I recently had a chance to do some refactoring of some Visual Basic code. I hadn't worked with it in several years. In particular, I hadn't worked with the object support that's in VB.Net. It's very striking how much it's like C# with different keywords.

My task was to convert some code from using web services (which were too slow) to just straight object code. Several factors came together:

• My unfamiliarity with VB.Net and web services.
• The fact that I was heading out of town for a week and didn't want to risk leaving problems.
• The team's use of source control which locks checked-out files. (I'm lobbying to change this.)
• A desire for extra care as the product has almost no automated tests.

This led me to do a scratch refactoring: refactoring with the intent of throwing it away and re-doing it. I refactored away two sets of web services, writing down each of the changes I intended to make (along with the name of the affected file.)

I found several benefits:

• I learned some little tricks for how to get the compiler to tell me what needed doing.
• Knowing I would throw the result away let the scratch refactoring go more quickly.
• I learned a couple tricks for the IDE.
• When I came back after my trip (to do the real thing), I felt like I was just flying through the changes.

I think it was Brooks who said something like, "It's faster to make a 6-inch mirror and a 10-inch mirror than it is to make a 10-inch mirror." I found that true in this case.

This work is licensed under a Creative Commons License.