Footgun #6 - Testing Too Many Things

(this mini-post is part of a series about good testing practices)

Just like with product code, if we put too many things in the same place we get a mess.

My rule of thumb is to try hard to test a single fact about the behavior of the code. And it helps if I use these specific words mentally.

SINGLE. FACT. About the BEHAVIOR.

Example

Let’s continue with our example from the previous post, and say we have a book store and we’re testing the edit book functionality.

For example, that’s a single fact about the behavior the code:

And, this is not a single fact, it’s too general:

How do they compare?

• Easy to understand?
  • Single fact test: It’s clear what the test checks. It’s clear that it only checks that.
  • General test: we’ll need to read and understand all the test code to know.
• Easy to debug?
  • Single fact test: If it fails, it’s clear what functionality stopped working. And because it’s small, it’ll be easy to debug it.
  • General test: if it fails, anything related to edit book might have failed. We’ll need to dig in. And it does a lot of things, so debugging might be a lot of work.

Conclusion

Try to have each test case will test a SINGLE FACT about the BEHAVIOR of the code.

This makes a huge difference and it’s worth it to invest a lot into this.