✅ Assertions — Hamcrest Deep Dive

Assertions — Hamcrest Deep Dive: A Hamcrest assertion is like a quality-control officer's measurement report: saying "PASS" is not enough — the report itself must show what was m

A Hamcrest assertion is like a quality-control officer's measurement report: saying "PASS" is not enough — the report itself must show what was measured, what it was compared to, and by how much it differed. You might ask whether `assertEquals(200, response.statusCode())` is sufficient — why use the longer `assertThat(statusCode, equalTo(200))` syntax? Because when `assertEquals` fails it only writes "expected: 200 but was: 401" — Hamcrest writes "Expected: a value equal to but: was ", and beyond that it lets you chain `hasItems`, `containsString`, `greaterThan`, and `hasKey` so you can verify the HTTP status, a specific body field value, and response time all in a single line. In Java this is similar to JUnit's `assertAll()` running multiple assertions together — the difference is that Hamcrest's error messages read almost like natural language. The real QA danger: when `assertTrue(response.statusCode() == 200)` fails it writes only "expected true but was false" — you cannot see the actual status code. That means hunting through 50 lines of CI logs to find the relevant code.

All Important Hamcrest Matchers

Micro Lab: REST Assured assertion writing

Replace the TODO line with the critical line from the expected solution. This is not a real runtime; the goal is to reinforce writing the correct structure in a controlled way.

Why 6 Different Matcher Categories — Isn't equalTo() Alone Enough?

equalTo/not/equalToIgnoringCase are the…

`equalTo`/`not`/`equalToIgnoringCase` are the EXACT-match family; `notNullValue`/`nullValue`/`emptyString` are EXISTENCE checks — one answers "WHAT is the value", the other "DOES a value exist".

greaterThan/between/lessThan are NUMERIC…

`greaterThan`/`between`/`lessThan` are NUMERIC range checks — you verify `age` falls in a REASONABLE range instead of being EXACTLY 25, which is a more REALISTIC test.

hasSize/hasItem/everyItem are COLLECTION…

`hasSize`/`hasItem`/`everyItem` are COLLECTION matchers — without them you would have to hand-write a `for` loop to verify an array.

`anyOf(equalTo(200), equalTo(201))` says "accept 200 OR 201" in ONE line — if the API sometimes returns 200 and sometimes 201, this ONE matcher suffices instead of writing two SEPARATE tests.

Soft Assertions — Collect All Failures

Step by Step: REST Assured assertion writing