Claude Code in Practice: Filling in Tests with Boundary Cases, Coverage, and Assertions

Claude Code, an AI coding assistant that can read through your entire project context and automatically debug errors, is changing how developers write unit tests. Based on a hands-on demonstration, this article breaks down how to use it to fill in boundary cases, improve coverage, and write effective assertions.

Why Is Claude Code Suited to Filling in Tests?

Unlike conversational coding tools such as ChatGPT and DeepSeek^Ad, Claude Code doesn't require you to log into a web page—after installation you use it directly inside your development tools. Its core difference is that it can read through all the code in your project: the contents of hundreds of files can be fed to the LLM as context, rather than handing over code snippets that you must manually move around and repeatedly debug as with chat-based tools.

This global context capability is exactly what filling in tests needs most: writing tests requires understanding a function's input parameters, dependencies, and boundary conditions, which is hard to do from an isolated code snippet alone. Claude Code can also automatically debug errors and ultimately deliver a runnable version of the code, which makes the "generate tests → run → fix" loop fully automatic.

Boundary Cases: Let the AI Actively Find the "Roads Less Traveled"

The easiest thing to miss when filling in tests is boundaries. Developers are used to writing "happy path" cases, while null values, extreme values, and abnormal inputs are often ignored. Claude Code's advantage is that it can read the branching logic inside a function and thus generate corresponding boundary cases for each conditional branch.

In practice, you can explicitly ask in the prompt: "Generate unit tests for this function, covering all if/else branches, including boundary cases such as null, empty string, overly long strings, and negative numbers for the input parameters." Because it can read through the project context, the generated cases fit the project's actual type definitions and utility functions rather than being made up out of thin air.

Coverage: From "Having Tests" to "Testing It All"

Insufficient coverage is a common problem with unit tests—it looks like there are tests, but in reality a large number of branches are never executed. After generating tests, Claude Code can combine them with the project's test run results to locate uncovered lines of code and then add targeted cases.

It's worth noting that the coverage number itself is not the goal. A more reasonable approach is to have the AI first output a list of "which functions lack tests and which branches are uncovered," then let you decide priorities and focus on filling in the core business logic.

Coverage usually refers to code coverage, which measures the proportion of code actually executed when tests run. Common metrics include line coverage (whether each line of code is executed), branch coverage (whether every branch of if/else, switch, etc. is reached), and function coverage. Widely used tools such as Istanbul/nyc, JaCoCo, and coverage.py instrument the code during test runs to record hits and generate reports. Branch coverage is stricter than line coverage because a single line of code may contain multiple conditional branches. Note that high coverage does not equal high-quality tests—tests may execute code without any effective assertions, so coverage should be used as a tool for discovering blind spots rather than the sole goal to pursue.

How to Write Meaningful Assertions

If assertions are too loose, the tests might as well not exist. Assertions generated by Claude Code usually verify return values but tend to overlook side effects and thrown exceptions. It's advisable to ask in the prompt for it to verify simultaneously: whether the return value matches expectations, whether the correct exception type is thrown, and whether the mocked dependencies are called as expected.

In addition, assertions should be as specific as possible. For example, don't just assert "the result is not empty"; assert "the result contains a specific field and its value equals the expected value." That way, when a test fails, the error message itself points to the problem.

A mock is a stand-in object that replaces real dependencies (such as databases, network requests, or third-party services) in unit tests, allowing the function under test to run in an isolated environment. Common frameworks include Jest and Sinon for JavaScript, unittest.mock for Python, and Mockito for Java. Mocks can not only return preset values but also record how they were called, so assertions like toHaveBeenCalledWith and assert_called_once_with can verify whether dependencies were called as expected and whether the arguments were correct. Assertions on mock calls can catch subtle problems where "the return value is correct but the internal logic took the wrong branch," making them an important complement to return-value assertions. But excessive mocking also couples tests to implementation details, making large numbers of tests fail during refactoring.

Side-by-Side Comparison: Why Claude Code

From the early Copilot plugin to Cursor, Trae, and then Open Code, AI coding tools have gone through several rounds of iteration. Copilot brought the disruptive feel of autocompletion, Cursor further realized automated coding, and Trae optimized Chinese-language understanding and is free in China. But in actual testing, Claude Code comes out ahead in accuracy, backed by the capabilities of models like Sonnet.

The author also admits that Codex is equally strong and comparable to Claude Code; Trae's free price is an advantage, but the accuracy of generated code drops on slightly more niche tech stacks. For rigorous tasks like filling in tests, accuracy is often more important than being free.

Sonnet mentioned in the article refers to the mid-tier models in Anthropic's Claude model series (such as Claude 3.5 Sonnet and Claude 3.7 Sonnet), which perform outstandingly on code generation and understanding tasks while costing less to run than the flagship Opus series. Claude Code is Anthropic's command-line/IDE-integrated coding agent tool; unlike the web-based chat, it can autonomously read files, execute commands, run tests, and iteratively modify based on error messages. Codex refers to OpenAI's code model series, initially Codex (which powered GitHub Copilot) and later evolving into the coding capabilities within the GPT series; in the context of this article it refers to the corresponding coding agent product. Understanding the distinction between models and tools helps in judging: accuracy depends both on the underlying model's capability and on whether the tool can obtain complete context and automatically verify.

Practical Advice

When handing test-writing to Claude Code, the prompt must be specific: state the function under test, the types of branches to cover, and the dimensions of assertion verification. After generation, be sure to actually run it and let the tool automatically debug errors rather than adopting the output directly. For tests of core modules, manually review whether the assertions are truly effective, to avoid "high coverage but testing nothing."