Lab 01 — Unified Diff Parser

Parse git format-patch output into structured data and detect whether a patch includes test coverage — the first thing an Apache committer checks in a review.

What you build

ClassResponsibility
FileDiffHolds file name, insertion count, deletion count; detects test files
PatchSummaryAggregate totals for an entire patch
PatchParserParses unified diff text into FileDiff list; produces PatchSummary

Run the tests

mvn clean test

Expected: 12 tests, 0 failures.

Key concepts

Unified diff structure

diff --git a/Foo.java b/Foo.java   ← file boundary
@@ -10,4 +10,6 @@                ← hunk header (not counted)
 context                          ← space prefix
-deleted line                     ← minus prefix
+inserted line                    ← plus prefix
  • +++ / --- lines are file-header markers, not counted.
  • The b/ path in the diff --git header is the canonical file name.

Test coverage signal

A patch that only modifies src/main/java/ with no changes to src/test/java/ (or files ending in Test.java) will cause most Apache reviewers to ask "Where is the test?" before any further review.

Interview talking points

  • "A bare git diff shows context lines (space), additions (+), and removals (-)."
  • "I always check git diff --stat first to get a quick overview before reading the hunk detail."
  • "Missing test coverage is the single most common review comment on first-time Apache patches."