14. How to Describe Tests

Welcome back to another episode of the Evil Geniuses Podcast. We are coming at you with something new this week! This episode will be the first time that we are not talking about a code problem that we’ve solved because we are going to take a stand, and our stand is about testing. We are diving into the ins and outs of how you describe your test. Here at Evil Geniuses, we believe that the description of a test should describe business value not implementation.

So stay tuned as we unpack the differences between business value and implementation descriptions, the opportunities that can come from rewriting code, and why naming your tests can take quite some time to fully master. For all this and more, keep listening!

Key Points From This Episode:

• Specific examples describe business value versus implementation.
• How the description sets you up to know what to look for when reading the test.
• Why a misdescription can make it hard to see if the test was successful.
• Understanding exactly who the test naming is for.
• Rewriting code allows you to know enough to better write business value descriptions.
• Why naming your tests takes a long time to master.
• And much more!

Talking Points

Tests should describe the business value and not the implementation

1. Different types

• Test that describes implementation:

1. 1. describing that a method or attribute returns a certain value
2. “it should equal 20”
3. “it should call YouTube API”
4. “it should call the render_text method”

• Test that describes business value

1. describing the reason to return a certain value

1. “it should have the amount given by the user”
2. “it should return video stats”
3. “it should render text”

1. Who are the tests for?

• Other developers reading the code
• Future you if you’re refactoring

1. Following this practice results in better tests

• Bad: “it should raise a PriceError”
• Good: “it should return an error when value exceeds max price”
• Not only about raising the error; it’s about notifying the developer and user that something exceeded the max price

1. Supports Refactoring

• clarifies the objective
• this makes it easy to change implementation because you aren’t confused about why a certain piece of code was written
• Ex: feel confident to refactor as long an error is raised when the max price is exceeded

1. Supports Feature Changes

• Feel more confident changing or removing test related to max price with description instead of just “exceeds 100”

Links Mentioned in Today’s Episode:

Evil Geniuses on Twitter

The Stand

Stride