Java Test Updater

A refactor broke 47 tests. Some of them should break — the behavior changed. Some of them broke because they were mocking internals. Don't bulk-update assertions; triage first.

Triage: why did this test break?

The last row is why you don't auto-update. A failing test might be right.

Step 1 — Separate compile breaks from assertion breaks

mvn test 2>&1 | tee test-output.log

Compilation errors (cannot find symbol, method X cannot be applied) are API drift — mechanical fixes. Assertion failures need judgment.

Step 2 — Compile fixes (mechanical)

Step 3 — Assertion triage (judgment)

For each failing assertion, read the change that caused it:

// Test:
assertEquals(new BigDecimal("27.80"), invoice.total());
// Fails: actual is 27.55

// Git blame the change:
// commit abc123 "Fix: tax rounds half-even, not half-up"

Half-even rounding is a bug fix. The old 27.80 was wrong. Update:

// Fixed in abc123: half-even rounding. Was 27.80 (half-up bug).
assertEquals(new BigDecimal("27.55"), invoice.total());

Versus:

// Test:
verify(taxCalculator).calc(eq(subtotal), eq(Region.US));
// Fails: calc was called with (subtotal, "US") — String, not enum

// Change: TaxCalculator.calc now takes String region, not Region enum

The test is verifying an internal call signature. It broke because an internal API changed. This test is over-coupled. Fix the immediate break, but also: does this verify need to exist? Is the call to taxCalculator the behavior, or an implementation detail?

Over-coupling patterns — loosen or delete

The regression trap

@Test void price_bulk_discount() {
    // 100 units → 10% bulk discount
    assertEquals(new BigDecimal("900.00"), engine.price(bulkOrder(100)));
}
// Now fails: actual 1000.00

The change was to TaxCalculator. Why did bulk discount break? This is a regression. Don't update the assertion. The test is doing its job — it caught a bug introduced by an unrelated change.

git bisect to find where, → regression-root-cause-analyzer to find why.

Batch update — only after triage

Once you've triaged all 47 and confirmed none are regressions:

// For snapshot/approval tests: one command updates all
// ApprovalTests: delete .received files after review, rename to .approved
// For explicit assertions: no shortcut — update each with its reason

There is no safe bulk-update for explicit assertions. Each one asserts something on purpose.

Do not

• Do not bulk-update assertions to "whatever the code does now." That's deleting tests with extra steps.
• Do not update a test without understanding why it failed. A regression looks exactly like an intentional change until you check.
• Do not loosen every verify. Some call verifications are the behavior — "sends an email" is a behavior you verify by checking the email client was called.
• Do not delete a failing test because you don't understand it. Figure out what it was protecting first.
• Do not add @Disabled as a fix. Disabled tests are deleted tests that still clutter the file.

Output format

## Failing tests
Total: <N>  Compile: <N>  Assertion: <N>

## Compile fixes (mechanical)
| Test | Error | Fix | Applied |
| ---- | ----- | --- | ------- |

## Assertion triage
| Test | Old expected | New actual | Cause | Classification | Action |
| ---- | ------------ | ---------- | ----- | -------------- | ------ |
(Classification: intentional-change | bug-fix | over-coupled | REGRESSION)

## Regressions found
<tests that are correctly failing — bugs in the change, not the test>

## Over-coupling cleanup
<verify/toString/PowerMock patterns loosened>

## After
Passing: <N>  Updated: <N>  Loosened: <N>  Deleted: <N>  Regression bugs filed: <N>