Spec your tests before writing them

If you’re struggling to get developers on your team to write integration or E2E tests when building new features, here’s a quick technique to help.

I generally find that the root cause of this is not laziness, but rather that they don’t understand what they should be testing. With teams new to serverless, this can be a problem as they often aren’t sure of the failure modes of the services they’re using.

Here’s the technique (which uses the Jest framework for JavaScript/TypeScript):

1. Create a new test file for the feature being built
2. Write out a list of it.todo(or test.todo) statements for each test case, including happy paths and error cases. Add comments in where the test title isn’t sufficiently descriptive.
3. Review the list with a colleague (over a PR or in a pairing session) before starting on implementation

That’s it!

Just taking the time to think through the different cases that your code needs to handle without the pressure of thinking about implementation details can really help clarify your thinking, improving the quality of both your test code and the application code.