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
| Class | Responsibility |
|---|---|
FileDiff | Holds file name, insertion count, deletion count; detects test files |
PatchSummary | Aggregate totals for an entire patch |
PatchParser | Parses 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 thediff --githeader 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 diffshows context lines (space), additions (+), and removals (-)." - "I always check
git diff --statfirst 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."