29 lines
1.1 KiB
Markdown
29 lines
1.1 KiB
Markdown
---
|
|
title: Tests can assert multiple things
|
|
date: 2024-01-19
|
|
permalink: archive/2024/01/19/tests-can-assert-multiple-things
|
|
snippet: |
|
|
Should each automated test only have a single assertion?
|
|
tags:
|
|
- software-development
|
|
- automated-testing
|
|
- test-driven-development
|
|
---
|
|
|
|
Similar to "a method should only have one return statement", I've seen similar advice when working with tests: "Tests should only have a single assertion".
|
|
|
|
I don't think this is true, and in my experience, you need multiple assertions to have a thorough test.
|
|
|
|
And, whilst similar assertions add some duplication, they can make the intent clearer and give better error messages.
|
|
|
|
Instead, I focus on one test case per test.
|
|
|
|
If I'm testing the following:
|
|
|
|
* A blog page exists.
|
|
* Only post nodes are visible.
|
|
* Only published posts are visible,
|
|
* Posts are returned in a specified order.
|
|
|
|
These will be split into separate tests - making it easier to read and maintain the code and have faster execution times by running only the tests I want with the minimum amount of code in each - regardless of how many assertions are in each.
|