Assertion Styles and Best Practices

Assertion libraries have evolved through several styles. The classic style, seen in xUnit-family frameworks like JUnit or early NUnit, uses static methods such as assertEquals(expected, actual) where argument order matters and errors can be silently backwards. The fluent style, popularized by libraries like Chai and AssertJ, reads like a sentence — expect(total).to.equal(180) or assertThat(total).isEqualTo(180) — which improves readability and removes ambiguity about which argument is expected versus actual. Matcher-based assertions, such as Hamcrest's assertThat(list, hasSize(3)) or Jest's expect(list).toHaveLength(3), compose small, reusable predicates (matchers) that can be combined, like anyOf(), allOf(), and not(), to express complex conditions clearly.

A well-written assertion produces a failure message that tells you what went wrong without needing to open a debugger. Comparing whole objects or collections with a single deep-equality assertion — expect(result).toEqual({ id: 1, name: 'Ada', active: true }) — is generally better than several separate field-by-field assertions, because most modern frameworks print a rich diff showing exactly which fields mismatched. Conversely, a single loose assertion like assertTrue(result != null) tells you almost nothing when it fails; prefer specific matchers like assertThat(result, is(notNullValue())) or, better, assert on the actual expected value so the failure message shows both what was expected and what was received.

Over-assertion happens when a single test checks unrelated facts — for example, asserting on a user's name, email, creation timestamp, and internal database row count all in one test named shouldCreateUser, which makes it unclear which fact actually matters to that test's purpose and produces noisy failures when any one field changes. Under-assertion is the opposite failure: calling a function and checking nothing meaningful about its result, such as only asserting that no exception was thrown, which lets real bugs slip through because the test never verifies the actual output was correct. The right balance is asserting exactly the facts relevant to the behavior described by the test's name — no more, no less.