How do you add tests to legacy code that has none?
Assesses fundamental understanding of Software Testing & QA conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Legacy code is often defined as code without tests, which makes changing it risky. The core technique is to introduce a seam, a place where behaviour can be substituted without editing the code under test.
Michael Feathers' approach:
- Identify a change point and find the smallest behaviour to pin down.
- Break dependencies by extracting interfaces, wrapping static or global calls, and injecting collaborators through constructors or parameters.
- Write characterisation tests that capture current behaviour, even if it looks wrong, so you know when you change it.
- Refactor under that safety net in small steps, then add tests for the new behaviour.
class Report {
Report(Clock clock, Mailer mailer) { ... } // seams injected
}
Tools help: approval or golden-master tests capture output for comparison, and dependency-breaking tools can substitute calls at link time. The risk is over-mocking, so prefer real fakes where feasible. Do not aim for full coverage first; cover the areas you are about to change.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.