Refactoring Safety

A solid, fast suite of tests that detects behaviour changes, because refactoring is by definition a change to structure that must not change behaviour, and tests are the only practical way to confirm that after every step. Fowler calls this the essential precondition. Solid means the tests check observable behaviour at stable boundaries with meaningful assertions, not just that code ran; fast means you can run them after each small change. When the area has no such tests, the first job is to write characterisation tests that capture what the code currently does, right or wrong. Without that safety net every refactoring is a gamble, and teams soon stop refactoring.

Because small steps keep the cost of a mistake tiny. If you make one refactoring, such as Extract Method or Move Method, and then run the tests, any failure is caused by that one change, so you can locate it immediately or simply revert and try a smaller step instead of debugging. Small steps also keep the code compiling and the build green, so you can commit, integrate and even deploy at almost any moment, avoiding long-lived branches and painful merges. A series of small green commits also makes later fault-finding with git bisect fast. Large leaps leave hours of broken code and failures with many possible causes.

It verifies observable behaviour at a stable boundary, not how the code is arranged internally. In practice that means calling a public API or use case and asserting on results or persisted state, for example that a placed VIP order has a discounted total and is stored, rather than verifying with Mockito that a calculator was called before a repository. It uses real collaborators where they are cheap, such as value objects and policies, and mocks or fakes only I/O gateways, so moving responsibilities between classes does not break it. It is fast, deterministic thanks to fixed clocks and no network, and its failure message points to the cause. Such tests survive restructuring.

Parallel change, also called expand-migrate-contract, lets you change an interface without a breaking big-bang step. In the expand phase you add the new structure alongside the old one, for example a new price(Product, PricingContext) method, make the old method delegate to it and mark it @Deprecated(forRemoval = true). In the migrate phase you move callers over one by one, keeping tests green and the system deployable after each step, possibly across several pull requests and modules. In the contract phase, once no callers remain, which IntelliJ's Safe Delete can confirm, you remove the old method. The same technique works for database columns, REST fields and event schemas.

Coverage only shows which lines or branches were executed by tests, not whether any assertion would fail if that code behaved differently. A test that calls a pricing method and asserts nothing gives full coverage and no protection. Mutation testing measures what you actually care about: tools such as PIT make small changes to the code, like turning > into >= or removing a method call, and run the tests; a mutant that survives reveals a behaviour change the safety net would miss. Use coverage to find untested areas, and the mutation score on critical modules, for example nightly with an 80 percent threshold, to judge the strength of the tests.

IDE refactorings understand Java's type system, so they miss anything that refers to code by string or from outside the compiled project. Typical cases are reflection such as Class.forName, Spring bean names in @Qualifier, property names in @ConditionalOnProperty and SpEL expressions, Jackson field names derived from getters or record components, Java serialisation, entity and field names inside JPQL strings or native SQL, Thymeleaf templates and scripts, and external consumers of public APIs, events or libraries. Renaming a record component can therefore silently change a JSON contract. Safeguards are context-loading smoke tests, approval tests of JSON, repository tests with Testcontainers, contract tests, and deprecation instead of renaming for public APIs.

CI is the shared, objective verification step after each small change. Every push runs the full unit and integration test suite, including tests against real databases with Testcontainers, plus architecture tests with ArchUnit or Spring Modulith and a static-analysis quality gate such as SonarQube on new code. Slower checks like mutation testing run nightly on critical modules. Because refactorings are integrated as small commits on trunk or short-lived branches, a failure points to a recent, small change that can be reverted quickly. CI also catches what local runs miss, such as other modules affected by a rename. To support refactoring, the pipeline itself must stay fast, ideally under ten minutes.

Refactoring at scale is a property of the engineering system, so the practices are organisational. Architect for testability, with dependency injection and framework-free domain logic, so most behaviour can be tested quickly. Treat build and test time as an architectural concern and keep pipelines fast. Use trunk-based development with small, separate refactoring and feature commits, and avoid long-lived refactoring branches. Lock in structural decisions with architecture tests and quality gates, and run mutation testing on critical modules. Use feature flags and canary releases where risk is high, and monitor error rates after deployments. Finally, make refactoring part of every feature rather than a project that needs special approval.