Add daily email for 2024-01-19
Tests can assert multiple things
This commit is contained in:
parent
c8d276611b
commit
6fcb504298
28
source/_daily_emails/2024-01-19.md
Normal file
28
source/_daily_emails/2024-01-19.md
Normal file
|
@ -0,0 +1,28 @@
|
||||||
|
---
|
||||||
|
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.
|
Loading…
Reference in a new issue