Testing behavior, not implementation details – part 2

This article explores how to identify and test observable behavior in data stores rather than implementation details. Observable behavior represents user-facing expectations rather than technical implementation choices.

Observable Behavior Definition

Rather than testing "where tasks are stored," tests should verify that:

• The user's open tasks must be listed
• The user's closed tasks must not be listed
• Other users' open tasks must not be listed

These represent what users actually care about experiencing.

Why This Matters

Users don't complain about database choices—they complain when they see others' tasks. The distinction clarifies what testing should target.

Testing Guidelines

Three primary strategies:

1. Fetch Multiple: Test every condition where results should/shouldn't appear
2. Fetch Single: Verify result returns and handle cases with no results
3. Storing: Confirm added objects are retrievable and constraints are enforced

Conclusion

Test quantity depends on user expectations, not method count. Understanding observable behavior enables developers to write tests that deliver genuine value rather than brittle, implementation-dependent assertions.