When Simple Assertions Fail: Mastering Fuzzy Matching in Unit Tests

Simple Assertions

Although there are many "good reasons" to avoid simple assertions, after trying many approaches you may admit that standards are a very good idea. Simple assertions sometimes cannot satisfy all testing needs.

// Pseudocode example
test('add new user to db' {
    user = createUser('John', 'Smith')
    id = system.addUser(user)
    readUser = system.retrieveUser(id)
    assert(user.firstName).is('John')
    assert(user.lastName).is('Smith')
});

The above simple test has several properties:

We use very simple test data "John" and "Smith".

The system under test is an API suitable for testing.

We assert with exact values that can be predicted before the test runs.

Any automatically generated content (e.g., id and userCreationDate) does not affect the test.

But

The example hints that the user may receive an id and a creation timestamp.

Writing such an assertion can be tempting:

readUser = system.retrieveUser(id)
    assert(user).is(expectedUser)

If expectedUser is set to contain the whole user object, the test performs a full object match. Using a single "expected" object for assertions is risky because it forces you to predict system‑generated values, leading to a lot of test noise.

Fuzzy Matching

// still a fictional language
    readUser = system.retrieveUser(id)
    assert(user).matches([
        { obj.firstName == 'John' },
        { obj.lastName == 'Smith' },
        { obj.id instanceof UUID },
        { obj.creationDate - now() < inSeconds(5) }
    ])

This combined test contains some precise assertions and several fuzzy ones.

Why Fuzzy Matching Is Tricky

The solution shows how to assert object types and approximate values meaningfully, even allowing regular‑expression matching on field contents. It lets you assert unpredictable values, but the assertion becomes large because it attempts a full match of the expected object.

Alternative Approaches

Perform fuzzy matching in separate tests, one at a time, to avoid fuzzy matching the entire object.

Filter out fields that cannot be matched against comparison data.

Design attributes with uniqueness to generate predictable values.

Write lower‑level, predictable tests instead of relying on high‑level fuzzy matching.

Conclusion

Using fuzzy matching in assertions is a useful technique, but it should be a last resort when no other method is available. More precise field matching can eliminate the need for fuzziness.