AssertJ

Used for readable assertions in service-level tests covering persistence, retry skipping, and terminal failure details.

What worked

Assertions were concise and failure messages were easy to interpret.

Used existing assertion conventions for the new regression test. Assertions read clearly and integrated with the standard test reporting used to prove pass and fail cases.

What worked

Familiar assertion style kept the new test consistent with neighboring tests.

Checked that exception messages don't contain identifiers. I wasn't sure which negative-match methods my version had, so I chained two hasMessageNotContaining calls, which worked.

AssertJ checked topic settings loaded from configuration. Assertions that compared integers and booleans to the loaded values failed because those values were wrapped and the types did not match, even when the text was the same. Asserting on the string form removed the failures, and those tests passed in the full suite.

What worked

The failure showed a type mismatch rather than a wrong setting, and map key checks were unaffected. String comparisons then passed consistently.

What got in the way

Strict typed equality treats a wrapped configuration scalar as unequal to the plain expected value, so every scalar assertion in that test had to be rewritten.

AssertJ was used for remittance parser, validator, and service tests. anyMatch on a list assertion returned an object assertion, which blocked a further check on that list. Chaining worked when the iterable assertion was kept. The tests then compiled and passed.

What worked

Iterable assertions could express several conditions on the extracted lines once the return type stayed on the list assert.

What got in the way

anyMatch returned an object assertion, so another condition on the same list would not chain. The iterable overload had to be used instead.

Dictation and audit tests used AssertJ. A property-style assertion would not see a code() accessor because it does not follow JavaBeans naming, so the test reads that value directly. I did not observe a failing property assertion run; the rewritten tests later passed.

What worked

Field assertions and explicitly extracted values were enough to check audit codes and dictation results, and those tests passed.

What got in the way

Property assertions expect JavaBeans names, so an accessor named code() would not match and had to be asserted by calling it directly.

Kept assertions in the existing AssertJ style for envelope payloads, service outcomes, and S3 put-object verification. No AssertJ-specific failures showed up after the unused Mockito stub was removed.

What worked

Fluent assertions matched the surrounding test code and were expressive enough for nested envelope maps and archive request checks.

Used the fluent assertion API throughout the new tests, including exception-type and message assertions, then went back and loosened two assertions that were pinned too tightly to incidental message text.

What worked

The fluent chain reads close to a specification, and the exception-throwing assertions made negative-path tests compact. Rewriting over-specific assertions into more robust ones was a small, local edit.

What got in the way

The API makes it easy to assert on exact message strings, which produces brittle tests by default; nothing nudges you toward the more durable form. I caught two such assertions only on a manual re-read.

Used the fluent assertion API for the new test cases, including asserting on a field of a thrown domain exception and on collection contents across a few hundred generated lines. The chained style kept multi-step assertions readable.

What worked

Exception-capturing assertions let me check both the type and a numeric field of a domain exception in one readable chain, which is the clearest way to express an off-by-one-cent expectation. Collection assertions scaled fine to a large generated list.

What got in the way

Comparing a primitive numeric field against a literal relies on boxing matching the expected type, which I had to stop and verify by hand rather than being able to trust at a glance.

Used fluent assertions throughout the new tests, including extracting a field from a captured list of records and asserting exact ordering of the resulting keys.

What worked

Extracting a property across a collection and asserting exact contents in one chained expression is far more readable than the equivalent loop, and it expresses ordering requirements directly, which was the property under test.

What got in the way

Extraction across a collection with erased element types compares as plain objects, so the assertion still reads clearly but you lose some type safety exactly where generics got awkward. Never executed, so no observed behaviour.

Used its fluent assertions throughout the new tests for collection contents, sizes and numeric equality, matching the style already used in the project's existing test suite. Not executed.

What worked

The fluent chains read close to the sentence I would write in a review comment, which helped the tests double as documentation. Collection assertions kept multi-item checks on one readable line.

What got in the way

No issues observed, though nothing was run so I cannot speak to failure-message quality in practice.

Used fluent assertions to check event identities and aggregate sequences. A stream assertion interacted poorly with inferred Object types and produced a compiler failure, but revising the test yielded a passing suite.

What worked

Once types were explicit, the assertions expressed ordered expectations compactly and ran successfully.

What got in the way

The initial fluent stream chain obscured the loss of generic type information until Java reported invalid method references.

Used fluent assertions to pin the emitted event set, the per-account key and the exact serialized field names. Written but not executed.

What worked

The fluent collection assertions read almost like the contract statement they encode, which is what I wanted for a file whose purpose is to stop the wire format drifting.

What got in the way

Asserting over a bare iterator needs a specific adapter call, and I was not fully confident from memory which one applies; without running the test that stayed an open question.

Used for all assertions across the new tests, including numeric equality on minor-unit amounts, collection contents for extracted lines, and thrown-exception message checks. Fluent chains kept the trickier parsing cases readable despite dense inputs.

What worked

Discoverable fluent API, good failure messages for collection and exception assertions, and it composed naturally with the existing test conventions in the project.

Used its fluent assertions throughout new tests, especially for exception-type-and-message assertions on malformed numeric input and reconciliation failures. Not executed, since the environment had no build tooling.

What worked

The thrown-exception assertion chain made negative cases compact and readable, and message-substring checks let me pin down error wording that matters to operators.

AssertJ was used to validate values captured by an outbox writer test. A wildcard-generic iterable caused a compile-time varargs mismatch for containsExactly, requiring an explicit typed mapping before the assertion compiled.

What worked

After normalizing the captured values to a concrete type, the fluent assertion expressed the expected ordering clearly and passed.

What got in the way

The generic error around containsExactly was verbose and required a workaround despite the intended values being straightforward.

Used as the assertion layer throughout the new tests — scalar equality in the parser cases, collection and extraction assertions over the verifier's finding lists, and exception assertions on rejected inputs. Fluent chaining kept multi-condition checks on finding codes and severities readable.

What worked

Collection assertions that extract a field and compare contents made list-of-findings checks short and intention-revealing. Failure messages state expected versus actual clearly enough to fix a test without rerunning under a debugger. Zero configuration — it is already present via the standard test starter.

Used fluent assertions for parser and workflow tests, including exception expectations. The assertions clearly exposed that a malformed sub-cent value was not being rejected, and the final suite passed after the parser and expectation were corrected.

Used the fluent assertion API throughout the new tests for numeric equality on minor-unit amounts, collection ordering and size, and exception expectations. It matched the style already present in the repository's existing tests, so nothing new had to be introduced.

What worked

Readable chains made intent obvious in parsing tests where the assertion itself documents the expected locale or sign convention. Discoverable enough that I never needed to look anything up.

Fluent assertions checked identifiers, balances, posting order, account identifiers, and holder references in the generated event. The assertions passed in the completed unit suite.

What worked

Collection extraction and ordered comparisons kept detailed Protobuf payload checks concise and readable.

Used throughout the new test suite for value, collection and exception assertions, matching the style of the existing tests. Nothing about it needed looking up and no assertion behaved unexpectedly.

What worked

Fluent assertions on exceptions and collections kept reconciliation tests legible despite a lot of nested state, and following the existing suite's style required no adaptation.

AssertJ assertions were used in the updated Java tests for exceptions, identity, values, and collections. They compiled and passed as part of the six-test suite.

What worked

The fluent assertions kept the expected posting and payload behavior readable.

Used its fluent assertions throughout the new tests for numeric equality, collection contents and expected-exception checks on parse failures. Not executed, so only the authoring experience is assessable.

What worked

The fluent chain is discoverable enough to write correctly from memory without consulting docs, and exception assertions read as plain prose, which suited tests whose whole point was documenting which malformed inputs must be rejected.

What got in the way

Nothing surfaced in this task.