Tests should be simple

The Good Enough Workshops focus on creating the minimum number of test cases to ensure that the requirements, business logic, and code logic are adequately covered. So, during the workshops, we discuss how many tests are needed to cover a feature or piece of logic, how to reduce them when you don’t have time or in the context of the risk, and more related to test case design.

But we don’t talk about writing test code. There is a lot of information about how to write test code; there are good books and articles about this if you need a deep dive.

I am sharing my concise perspective on establishing a style guide or guidelines for writing tests in Minitest or RSpec.

1. Keep tests plain and simple

Avoid complexity. A big part of avoiding complexity is avoiding abstractions in test code as much as possible. Don’t create abstractions with test code.

You should write explicit, straightforward code. Focus on writing tests so that when read, they can fit in your mind in a single pass. There should not be a need to open other files or go back and forth between various sections in the same file.

Don't try to be smart with your code. Don't apply SOLID.

Test code should flow like a recipe from top to bottom.

2. Each test should be read like a story

The story should describe clearly:

• preconditions (state of the system before running the main action)
• the action
• the expectation or assertion
• postconditions when needed (the state of the system after the test run)

When you need to write preconditions and postconditions, make sure the test will fail if they are not matched.

Example:

• Use create! instead of create if you need to create AR
• Use validate! on a new instance when you don't want to create it

3. Having the same code across multiple tests is allowed and encouraged

Duplicated code is allowed because it makes the system resilient to unintended changes.

Make the assertions explicit and, depending on the test’s purpose, assert them with concrete values rather than references to elements from the tested code.

4. There should be positive and negative tests to limit the confirmation bias

Make sure you have also written negative scenarios to cover the features/logic that you are testing.

You should verify how your system handles invalid, unexpected, error-prone input or erroneous conditions.

Write at least one test that will cover the case where your feature/business logic should not work and will throw an error, return false/nil/empty ...

5. Tests that never failed cannot be trusted

Consider that any tests that never fail cannot be trusted; thus, each test should have failed at least once on your computer before pushing the code.

For each test, ensure you execute it at least once in a scenario where you have modified the code so that the test is expected to fail.

Don’t commit a test that never failed on your local machine.