Skip to lesson

AnthropicClaude Certified Architect – Foundations2026-101.6 Design task decomposition strategies for complex workflows

Map legacy behavior before choosing tests

Completed by the knowledge check

Learning objective

Map a legacy codebase, prioritize high-impact testing or change targets, and adjust the plan as dependencies emerge.

Core idea

“Add comprehensive tests” describes an outcome without identifying the work that produces it. In an unfamiliar legacy repository, first establish how important behavior crosses the codebase. Then choose testing or change targets whose correctness matters to that behavior, and revise the order when dependencies reveal missing prerequisites.

The CCAR-F exam guide explicitly describes mapping structure, identifying high-impact areas, and creating a prioritized plan that adapts as dependencies emerge. Anthropic’s Claude Code workflows supply the working approach: start with an overview, narrow into components, identify untested code, follow existing test conventions, and run the resulting tests.

See 1.6.3 for revising investigation hypotheses. Here the special problem is prioritization: you need to choose among many plausible tests before you understand every file. A map and a first bounded target make that choice reviewable without pretending the repository is already fully understood.

How it works

Map behavior as well as directories

Anthropic’s codebase-exploration workflow starts with a high-level overview and proceeds to architecture patterns, data models, and specific features. Use that sequence to ask where requests enter, where decisions happen, and where state or external effects leave the process. A directory inventory alone cannot show which module controls an important outcome.

In Claude Code, Read supplies file content and Bash supports searches and project commands. The tool reference documents that macOS, Linux, and WSL omit Glob and Grep from the default tool set; searches use Bash there. Assign the exploration by question and source rather than assume a particular search tool is available.

Ask Claude to connect a selected behavior from entry point to result. For an invoice-processing application, that might mean an import handler, validation rules, calculation logic, persistence adapter, and notification consumer. These names are example application components, not Claude tools. The useful output explains the relationships and identifies the source that supports each one.

Also inspect existing tests and their execution instructions. Anthropic states that Claude examines existing tests to match project frameworks, style, and assertion patterns. Give it those files rather than ask it to invent a parallel test system before learning the repository’s conventions.

Choose the first target from impact and evidence

After you have a map, ask which important behavior lacks a meaningful check. Anthropic’s testing workflow begins by finding uncovered functions, then adds tests for behavior and edge cases. Use uncovered code as an input to the choice, rather than treat every uncovered function as equally urgent.

For this plan, a high-impact target is a behavior whose failure would materially affect the requested outcome: incorrect totals, a duplicate external action, or an authorization decision, for example. Connect each proposed test to that behavior and the source path that implements it. This is a prioritization criterion for your assignment, not a documented automatic risk score in Claude Code.

Require the plan to name the selected target, the behavior to verify, the relevant existing tests, and the check to run after adding the test. Anthropic’s best practices recommend specific prompts and executable verification. A plan that says “increase coverage in billing” leaves Claude to guess the expected behavior and where the work should start.

Separate evidence of missing coverage from evidence of a defect. A branch without a test deserves investigation; it does not establish that its implementation is wrong. Begin by checking the required behavior and writing a test that makes that behavior observable. Change production code only when the assignment and evidence justify the change.

Resolve dependencies before generating a broad test suite

A selected function might depend on repository fixtures, application configuration, or an external adapter. Ask Claude to inspect those dependencies before producing tests for every mapped module. Anthropic warns that poorly scoped exploration consumes context; a bounded first target reveals relevant constraints with less unrelated reading.

Suppose the plan begins with invoice totals, but reading the calculation path reveals a shared currency parser. The parser determines whether the totals receive cents or decimal currency values. Move a parser-behavior check ahead of the calculation tests, because the downstream tests need a trustworthy representation. When task-tracking tools are available, record the parser check with TaskCreate and use TaskUpdate to update the totals task’s dependencies so the parser check is its prerequisite. See 1.6.3 for the model-specific defaults, opt-in options, and session exceptions. Keep the totals as the original outcome; the dependency changes the route to it.

Another dependency might change the kind of test required. If a defect can arise only between a producer and consumer, isolated tests of each module do not establish that the contract agrees. Add the cross-file check described in 1.6.2. The map tells you which relationship the test must exercise.

Avoid responding to every discovered coupling with a refactor. First determine what check demonstrates the behavior and whether existing test patterns already support it. If a prerequisite production change is necessary, include it explicitly in the proposed plan and explain why the selected test cannot establish the required behavior without it.

Keep planning and verification visible

Start with claude --permission-mode plan to request a prioritized proposal for unfamiliar or multi-file work; see 1.6.3 for plan review and its permission boundaries.

For each completed target, ask Claude to run the relevant test and return the command, result, and remaining gap. Its agentic loop uses tool feedback to decide subsequent actions. A failure may expose a dependency that needs investigation; a successful check may let the plan advance to the next behavior.

If the baseline tests already fail, preserve that evidence before interpreting added-test results. Ask for a check that distinguishes the selected behavior from the unrelated baseline failure. “The suite is red” is too coarse to explain whether your first target is protected or still unverified.

Key distinctions and trade-offs

Architecture map versus file list: A file list establishes inventory. A behavior map establishes dependencies and the path whose outcome you intend to protect. The latter supports test selection.

High impact versus easy coverage: A small helper can be quick to test but irrelevant to the most consequential behavior. Conversely, a shared parser can be both small and critical because many paths depend on it. Inspect the relationship rather than rank by file size.

Test target versus change target: A test checks a requirement. A production change alters the implementation. Lack of tests alone is not evidence that the implementation needs rewriting.

Mapping adds initial work, but reduces tests built around mistaken interfaces or irrelevant modules. Keep the map sufficient for the first decision; an exhaustive repository description can delay the very verification you are trying to add.

Architecture / decision scenario

A code-generation agent receives the request to add comprehensive tests to a legacy invoice application. It begins in plan mode, identifies the import-to-total path, reads existing tests, and proposes totals calculation as the first high-impact target. Cosmetic formatting helpers remain lower priority because they do not determine the invoice amount.

Exploration then reveals a shared currency parser used by both batch import and interactive entry. The agent revises the plan to verify that representation first, followed by totals tests and an integration check for both entry paths. It uses the repository’s existing test conventions instead of introducing another framework.

The first parser test exposes inconsistent handling between the two callers. The proposed change target becomes the boundary that creates the inconsistency, with a check for the affected invoice result. After the correction, the agent runs the targeted tests and reports their results before proceeding to another mapped behavior.

The plan remains comprehensive in intent but incremental in execution. Each discovery can alter prerequisites and priority, while the acceptance criteria continue to require trustworthy invoice behavior rather than a large count of generated test files.

Common exam traps

  • Generating tests across the repository before identifying important behavior.
  • Treating the directory tree as a complete architecture map.
  • Ranking work solely by uncovered lines or ease of test generation.
  • Mocking a dependency without inspecting the contract it supplies.
  • Keeping the original order after discovering a shared prerequisite.
  • Rewriting production code merely because it lacks tests.

What to remember

Map the behavior, inspect existing tests, choose an explicit high-impact target, and verify it. Let discovered dependencies change the prerequisites and test scope, while the original behavioral outcome continues to determine success.

Knowledge check

References