IDE & Automated Refactorings — Find the Bug¶

Source: Martin Fowler, Refactoring (2nd ed.); JetBrains IntelliJ IDEA & ReSharper refactoring docs

Each scenario: an "automated" refactoring ran, the IDE reported success, and behavior silently changed or a reference was missed. Find the bug, explain why the tool's guarantee didn't cover it, and fix it. The pattern to internalize: the green checkmark proves the resolvable references were handled — not that behavior was preserved.

Scenario 1 — The rename the compiler couldn't catch¶

// BEFORE
class PaymentProcessor {
    public void processCharge(Money m) { ... }
}
// elsewhere, a job runner:
Method handler = clazz.getMethod("processCharge", Money.class);
handler.invoke(processor, amount);

A developer ran Rename processCharge → charge. Build is green, unit tests pass. In staging, the nightly job throws NoSuchMethodException.

Scenario 2 — Change Signature picked a different overload¶

// BEFORE
void log(String msg)            { writer.write(msg); }
void log(String msg, int level) { writer.write("[" + level + "] " + msg); }

// call site:
log("disk full");

A developer used Change Signature to add an int level parameter to the first log, with default 0. Build green. Now log("disk full") prints [0] disk full in some places and the un-leveled line in others, inconsistently.

Scenario 3 — Inline doubled a side effect¶

// BEFORE
int id = nextSequence();   // increments a counter, returns new value
record(id);
audit(id);

A developer ran Inline Variable on id. Build green, the unit test (which stubbed nextSequence to return a constant) passes. In production, audit records reference a different id than the data records.

// AFTER inline — bug
record(nextSequence());
audit(nextSequence());     // <-- second call increments again -> different id!

Scenario 4 — The "zero usages" deletion¶

public class FeatureFlags {
    public boolean betaCheckout() { return get("beta_checkout"); }   // Find-Usages: 0
}

Find-Usages reported 0 usages of betaCheckout(), so it was deleted. The next release silently disabled beta checkout for everyone.

Scenario 5 — Encapsulate Field broke the wire format¶

// BEFORE — serialized to JSON by a field-access mapper
public class Dto {
    public String userId;
}
// consumer expects: {"userId": "..."}

A developer ran Encapsulate Field on userId (now private, with getUserId/setUserId). Build green, the round-trip unit test passes. A downstream consumer starts receiving {"userID": ...} — or the field vanishes.

Scenario 6 — Rename leaked across a duck-typed boundary (Python)¶

class Invoice:
    def settle(self): ...

class Subscription:
    def settle(self): ...     # unrelated, same name

def close(item):
    item.settle()             # item could be either

In PyCharm a developer renamed Invoice.settle → finalize. The tool also renamed Subscription.settle → finalize and the item.settle() call. Now Subscription callers elsewhere break, and an Invoice-only test still passes.

Scenario 7 — Move Class stranded a Spring bean¶

// Moved com.app.PaymentService -> com.app.billing.PaymentService via Move Class
// applicationContext.xml:
//   <bean id="paymentService" class="com.app.PaymentService"/>

Move Class updated all Java imports; build green; unit tests pass. The app fails to start: ClassNotFoundException: com.app.PaymentService.