Practice legacy code vocabulary from Michael Feathers: characterization tests, seams for testing, zero-documentation modules, and the discipline of writing tests before refactoring.
0 / 16 completed
1 / 16
Michael Feathers defines legacy code as code that:
In 'Working Effectively with Legacy Code', Feathers defines legacy code as code without tests — regardless of age. Tests are what make code safe to change.
2 / 16
A '_____ test' documents the current behavior of legacy code before refactoring begins.
A characterization test (Feathers) captures the current behavior of code — even if that behavior is wrong — so that changes don't unintentionally alter what the code does.
3 / 16
'We added a _____ to enable testing.' What is inserted into legacy code to allow dependencies to be replaced in tests?
A 'seam' (Feathers) is a place in code where behavior can be changed without editing the code itself — enabling dependency injection and testability in otherwise untestable legacy code.
4 / 16
'We're writing tests _____ refactoring.' What is the correct order?
The legacy code discipline requires writing characterization tests BEFORE refactoring — so you have a safety net that detects if the refactoring accidentally changes behavior.
5 / 16
'The legacy module has zero _____.' What is missing that makes the module especially hard to work with?
Zero documentation makes legacy code especially risky — there is no record of intent, edge cases, or design decisions. Characterization tests serve as a form of executable documentation.
6 / 16
Sarah, a senior developer, left a comment on a code review for the `OrderProcessingService`. She wrote: 'This method is tightly coupled to the database schema. We should refactor it to use an abstraction layer.' What does 'tightly coupled' most accurately describe in this context?
'Tightly coupled' refers to a situation where components are interdependent and highly reliant on each other's internal details. In this case, the method directly uses database specifics, making it fragile and difficult to change without affecting the code itself. This contrasts with loosely coupled systems that have well-defined interfaces.
7 / 16
Jessica received an API response from a legacy service: `{"status": "error", "message": "Invalid user ID format.", "code": 400}`. What does the 'code' field in this JSON response typically represent?
In RESTful APIs, the 'code' field almost universally represents the HTTP status code (e.g., 200 for success, 400 for bad request). This allows clients to interpret the response based on standard HTTP conventions and handle errors accordingly.
8 / 16
Mark is reviewing a PR that introduces a new feature into an older module. He sees the following comment from another developer: 'This code directly accesses the internal state of the `Customer` object. We need to introduce dependency injection to decouple this logic.' What does Mark likely mean by 'dependency injection' in this context?
Dependency injection is a design pattern where external components provide dependencies instead of the class itself creating them. Mark's comment refers to decoupling the code by providing an interface for access, rather than direct access to the `Customer` object's internals. Options A and B describe database changes or value replacements, not dependency injection.
9 / 16
During a stand-up meeting, David says: 'We're trying to add some integration tests for the `PaymentGateway` module, but it's incredibly difficult because it relies on legacy code that doesn't have any mocks or stubs.' What is David most likely referring to when he mentions 'legacy code' in this situation?
David is highlighting code that's old and poorly designed for testing. 'Legacy' here refers to the age and lack of testability features – typically a lack of mocks, stubs, or interfaces – within the `PaymentGateway` module. Options A, C, and D describe other potential issues but don't capture the core meaning of 'legacy' in this context.
10 / 16
A PR description reads: 'Refactoring the `UserAuthenticationService` to use a dedicated authentication provider. This will improve security and reduce code duplication.' What is the most likely benefit of refactoring this service as described?
The description explicitly mentions 'reduced technical debt' and 'improved maintainability,' which are key benefits of refactoring. While performance improvements might be *a* benefit, the primary goal here is to address the code's existing problems – making it easier to understand and modify in the future.
11 / 16
Sarah, a developer, leaves this comment on a code review for a legacy module: 'This class is excessively large and complex. It should be broken down into smaller, more manageable units.' What problem does Sarah identify in the existing code?
Sarah is pointing out 'code duplication' as a key issue. Large and complex classes often lead to duplicated logic, making the code harder to understand, maintain, and test. Options B, C, and D represent other potential problems but aren't the core issue Sarah highlights.
12 / 16
John, a junior developer, is struggling to understand why the `DataValidationService` throws an exception when processing certain input. The code has been around for years and hasn't been touched since its initial implementation. What is the most likely reason this service isn't working correctly?
Insufficient documentation is the most common cause of issues with legacy code. Without clear specifications for input formats, developers struggle to understand and correctly handle unexpected data. Options B, C, and D represent potential bugs introduced during updates or misinterpretations of the original design, but lack the direct connection to the core issue of missing information.
13 / 16
During a Slack conversation about improving the `InventoryManagementSystem`, Liam says: 'We need to introduce some mock objects to isolate the legacy code during testing.' What is the primary purpose of using mock objects in this scenario?
Mock objects are specifically designed to mimic the behavior of dependent components without requiring those components to be fully functional or even present. This allows developers to isolate and test the `InventoryManagementSystem`'s core logic independently, preventing issues caused by external dependencies or complex integrations – a key benefit in legacy code refactoring.
14 / 16
Maria is reviewing a PR that aims to modernize the `ReportingService`. The PR includes this comment: 'We're writing tests before refactoring.' What does this indicate about the team's approach?
Writing tests before refactoring aligns with the TDD methodology. This strategy ensures that every change made to the legacy code is validated by automated tests, reducing the risk of introducing new bugs and providing confidence in the stability of the system during the refactoring process. The 'Big Bang' approach is generally discouraged for complex legacy systems.
15 / 16
David, a senior developer, comments on a code review: 'The legacy module has zero boundary conditions.' What does this likely mean?
Boundary conditions refer to the specific limits or constraints that a system must handle correctly. When a legacy module lacks them, it suggests deficiencies in its error handling – meaning it doesn't adequately manage invalid inputs, unexpected errors, or exceptional situations, leading to instability and potential failures.
16 / 16
Emily is documenting a PR that refactors the `UserSessionService`. The description includes: 'This will improve security and reduce code duplication.' Which of the following best explains why this refactoring likely addresses these concerns?
Consolidating session management logic into a single service directly addresses code duplication. This simplifies maintenance and reduces the risk of inconsistencies arising from multiple implementations. While options B, C, and D represent potential benefits of modernizing a system, they don't directly explain why the refactoring improves security or reduces code duplication.
This is a Refactoring Language exercise set. It walks through 16 scenario-based multiple-choice questions built around real usage of refactoring language terminology that IT professionals encounter on the job.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to complete with no account, sign-up, or paywall.
How many questions are in this exercise?
This set contains 16 questions. Each one shows immediate feedback and a detailed explanation after you answer, so you learn the correct usage right away rather than waiting for a final score.
Do I need prior experience to complete this exercise?
No prior experience is required. Each question includes a full explanation covering the reasoning behind the correct answer, so the exercise itself teaches the refactoring language vocabulary as you go.
Can I retry the exercise if I get questions wrong?
Yes — use the "Try again" button on the results screen to reset your answers and go through all the questions again. There is no limit on attempts.
Is my progress saved?
Your answers and score for the current session are tracked in the browser as you go. No account or login is needed, and there is nothing to install.
What if I don't understand a term used in a question?
Read the explanation shown after you answer each question — it breaks down the correct term in plain English with a real-world example. You can also check the site Glossary for quick definitions.
How is this different from reading a blog article on the topic?
Exercises like this one are interactive drills that test and reinforce specific vocabulary through multiple-choice questions, while blog articles explain concepts in prose. Practising here after reading builds active recall, not just passive recognition.
Where can I find more Refactoring Language exercises?
See the Refactoring Language exercises hub for the full set of related pages, or browse all exercise categories from the main Exercises index.
Can I use this exercise to prepare for a technical interview?
Yes — refactoring language vocabulary comes up often in technical discussions and interviews. Pair this exercise with our dedicated Interview Preparation section for role-specific practice.