Programmer tests should:

Minimize programmer waiting.
Run reliably.
Predict deployability.
Respond to behavior changes.
Not respond to structure changes.
Be cheap to write.
Be cheap to read.
Be cheap to change.

- @KentBeck

More: https://medium.com/@kentbeck_7670/programmer-test-principles-d01c064d7934

#tdd

Let's consider some popular testing styles.

Jest Snapshot:
✅ Minimize programmer waiting.
✅ Run reliably.
❓ Predict deployability.
⚠️ Respond to behavior changes.
⚠️ Not respond to structure changes.
✅ Be cheap to write.
⚠️ Be cheap to read.
✅ Be cheap to change.

Image-based test (For example @chromaui or @percy_io)

⚠️ Minimize programmer waiting.
✅ Run reliably.
✅ Predict deployability.
⚠️ Respond to behavior changes.
✅ Not respond to structure changes.
✅ Be cheap to write.
✅ Be cheap to read.
✅ Be cheap to change.

Traditional unit test:

✅ Minimize programmer waiting.
✅ Run reliably.
⚠️ Predict deployability.
✅ Respond to behavior changes.
⚠️ Not respond to structure changes.
✅ Be cheap to write. (Yes, assuming pure func)
✅ Be cheap to read.
✅ Be cheap to change.

Automated integration test (for instance, @Cypress_io or Selenium)

⚠️ Minimize programmer waiting.
✅ Run reliably.
✅ Predict deployability.
✅ Respond to behavior changes.
✅ Not respond to structure changes.
✅ Be cheap to write.
✅ Be cheap to read.
✅ Be cheap to change.

Takeaway: Approaches have tradeoffs.

Unit tests provide instant feedback.

Integration tests better predict deployability, and aren't impacted by structure changes. However, their feedback loop is too slow to rely upon alone.

So I suggest using a combination of approaches.

View original on X