Test Design

Software Engineering 10 Sep 2026 12 min read

Choosing Sociable or Solitary Unit Tests

Choosing Sociable or Solitary Unit Tests A unit test fails after a harmless refactor. The production behaviour is still correct, but the test expected an internal collaborator to receive exactly three calls. Elsewhere, a different unit test passes even though two real classes no longer work together, because both sides were replaced with mocks. Both tests are isolated in some sense, yet they give poor feedback for different reasons. The useful question isn’t simply whether unit tests should use mocks. It is where the test boundary should be.

Software Engineering Testing

Software Engineering 08 Sep 2026 9 min read

Testing Test Suites with Mutation Testing

A test suite can execute every line of an important function and still fail to notice that the function is wrong. Coverage tells you which code ran during tests. It does not tell you whether the tests would detect a meaningful mistake in that code. Mutation testing examines that missing question. A mutation testing tool makes small changes to production code, one change at a time, and runs the relevant tests. If the tests fail, they detected the changed behavior. If they still pass, the altered code has exposed something worth investigating.

Software Engineering Testing

Software Engineering 08 Sep 2026 9 min read

Reducing Test Combinations with Pairwise Testing

Configuration-heavy software creates a testing problem that grows faster than it first appears. A feature may behave differently by account type, payment method, region, browser mode, storage backend, or feature flag. Testing each choice separately can miss interaction bugs, while testing every combination can become impractical. Pairwise testing is a combinatorial test-design technique for this situation. Instead of requiring every complete combination, it constructs a set of tests in which every pair of parameter values appears together at least once.

Software Engineering Testing

Software Engineering 06 Sep 2026 9 min read

Building Focused Test Data with Test Data Builders

Tests become hard to understand when creating the object under test requires many values that are irrelevant to the behavior being checked. A test for an overdue invoice may need an identifier, customer, currency, issue date, due date, line items, tax settings, and status even though only the due date matters. Copying complete fixtures into every test makes that irrelevant detail visible everywhere. Sharing one mutable fixture hides the detail, but it can make tests depend on each other. A test data builder offers a middle path: it creates a valid object from sensible test defaults while letting each test override only the values important to its scenario.

Software Engineering Testing