A test passes. Great! But does it really mean your code is working as expected? Not necessarily.Sometimes the values you choose in your tests can create a false sense of security, especially when dealing with default values.
Consider this snippet of a simple map class and its corresponding unit test:
Implementation
Test
void MyMap::insert(int key, int value) {
// Oops! The map entry is default-initialized,
// the second parameter is not used.
internal_map_[key];
}
TEST(MyMapTest, Insert) {
MyMap my_map;
my_map.insert(1, 0);
// This passes!
EXPECT_EQ(my_map.get(1), 0);
}
The test passes, but the insert method is broken! It never actually stores the value. The test only passes because the default value for an integer in the map (0) happens to match the value used in the test.
When choosing test values, consider the following:
Test with non-default values. Explicitly test with values different from the type's default (e.g., non-zero numbers, non-empty strings, enum values other than the one at index 0). This provides greater confidence that your code is actually using the provided input.
TEST(MyMapTest, Insert) {
MyMap my_map;
my_map.insert(1, 5);
// This test would fail and reveal the bug in
// the implementation above: “Expected 5, got 0”.
EXPECT_EQ(my_map.get(1), 5);
}
Test multiple inputs that cover different scenarios, where it is reasonable to do so.
Consider empty/missing/null values, numerical boundaries, and special cases that trigger complex logic. Try to cover all distinct code/logic paths.
Consider using fuzzing to more thoroughly cover the input domain.
Use different values for each input. This guarantees the code under test doesn't accidentally reuse a single input or switch their order. Parameterized testing can also help test a large variety of inputs with minimal code duplication.
When responding to code review comments, responses like “Done,” “Updated,” or “Fixed” are commonly used to indicate addressing a suggestion. However, sometimes, a little extra context adds a lot of clarity.
Next time you resolve a code review comment, ask yourself: "Is how I addressed the comment completely obvious from the code change and comment thread?" If not, supplement your response with a brief note to clarify the “why” or “how.” Your reviewers will thank you.
When is it helpful to add context to a code review comment response?Here are a few examples:
Your code change doesn't fully explain how you addressed the comment. Providing a brief summary helps the reviewer verify the changes without re-examining every line of the delta, and creates a clearer historical record.
Reviewer:
This approach seems risky. It might not handle all the edge cases properly.
Less helpful response:
More helpful response:
Author:
Updated.
Good catch. I've added checks for null, empty, and negative inputs, each with a new test case. Thanks!
You made a design choice or trade-off that isn't self-evident. Capturing the reasoning behind a choice provides valuable context. Note that non-obvious design choices within the code should ideally be explained in code comments or the commit description as well.
Reviewer:
Consider using a more performant library for this data transformation.
Less helpful response:
More helpful response:
Author:
I’ll go with Y.
Done. I considered Library X, but stuck with Library Y because our datasets here are typically small, so the performance difference is negligible, and Library Y has a much simpler API.
An offline discussion influenced the solution. Briefly summarizing the outcome or key reasoning from an offline sync ensures that other reviewers, who only see the final code change, can grasp the “why”.
Reviewer:
This logic seems a bit complex. Consider a simpler way to handle these.
Less helpful response:
More helpful response:
Author:
Fixed.
As we discussed offline, this complexity is required to maintain backward compatibility with legacy data formats. I’ve added a comment in the code to clarify this. Thanks!
There are multiple ways to address the comment. Clearly stating which option you selected and the reasoning behind that choice over other alternatives helps reviewers.
Classes require various objects and parameters to function. The "Construct with Collaborators, Call with Work" guideline can help you construct effective inputs:
Use the constructor for collaborators—the dependencies that establish the object’s identity. Collaborators stay with the object for its lifetime to enable it to fulfill its ongoing duties.
Pass work—the parameters that change with each interaction—to methods. Unique to each call, these inputs provide the specific data needed for an operation such as a file path or database query.
Consider a ReportGenerator that needs a database, a formatter, and a date range to generate a report. The database and formatter, as collaborators, are injected via the constructor, while dateRange, which varies per report generation, is passed as a method parameter to the generate method:
class ReportGenerator {
private final Database database;
private final Formatter formatter;
// database and formatter are passed as collaborators.
A single ReportGenerator object can generate multiple reports with different date ranges:
ReportGenerator generator = new ReportGenerator(database, formatter);
Report report1 = generator.generate(dateRange1);
Report report2 = generator.generate(dateRange2);
Following the "Construct with Collaborators, Call with Work" guideline promotes:
Reusability: Enables instances to be used for multiple, distinct operations.
Testability: Separates dependency setup from business logic.
Cleaner code: Hides implementation dependencies from the object’s users.
Predictable behavior: Locks in dependencies at creation time.
Note that the definition of "collaborator" versus "work" depends on the object's identity. For example, a RequestMessage could be a collaborator for a RequestHandler if the handler operates on a single request, or work if the handler processes different requests with each method call.
Can you spot the wasted CPU cycles in the map usage?
if employee_id in employees:
mail_to(employees[employee_id].email_address)
The redundant lookup caused the waste by performing a check (in) and a fetch ([]) as two separate operations when one is sufficient.
Every lookup involves a cost—whether it's computing a hash and scanning buckets or performing an O(log n) traversal. These costs add up quickly. But avoiding them isn’t just “premature optimization”—it’s about writing cleaner, more robust code that stays efficient at scale and prevents potential race conditions.
Instead of paying this cost twice, perform the lookup once and reuse the result:
if (employee := employees.get(employee_id)) is not None:
mail_to(employee.email_address)
Assigning the search result to a variable avoids a second lookup. This efficiency is native to Go via the “comma ok” idiom (val,ok:=map[key]) and C++ using map.find(key), both handling retrieval and existence in a single pass.
The same inefficiency applies when counting or initializing default. Stop checking for presence; instead, use idioms that handle missing keys automatically at the container level:
Here are some details depending on which language you use:
C++:operator[] returns a reference to the value—automatically inserting a default (like 0) if the key is missing—allowing the increment to happen in place.
Java: Use map.computeIfAbsent() to perform retrieval and updates in a single call. This is more concise and, on concurrent collections, has the potential to be thread-safe—preventing the “check-then-act” race conditions common with separate contains and put calls.
Python: Use collections.defaultdict to handle defaults at the container level, which pushes the logic into optimized C code for better performance and robustness. Note that the += operation (shown later in the above code sample) still involves both a read and a write operation.
Go: Use val,ok:=map[key] to handle retrieval and existence in one memory access.
Test-Driven Development (TDD)is the practice of working in a structured cycle where writing tests comes before writing production code. The process involves three steps, sometimes called the red-green-refactor cycle:
Write a failing test
Make the test pass by writing just enough production code
Refactor the production code to meet your quality standards
Research shows TDD has several benefits:it improvestest coverage, reduces the number of bugs, increases confidence, and facilitates code reuse. This practice also helps reduce distractions and keep you in the flow. TDD also has its limitations and is not a silver bullet! See the Wikipedia article about TDD for a detailed explanation and references.
Here is a short practical example. Assume you need to modify the following voting algorithm to support the option for voters to abstain:
def outcome(ballots):
if ballots.count(Vote.FOR) > len(ballots) / 2:
return "Approved"
return "Rejected"
1. We start by writing a failing test - as expected, the test doesn't even compile:
