Enable, Execute, Expect
Much ink has been spilled (metaphorically) around the topic of writing good unit tests. One of the best patterns I’ve seen for thinking about how to write good unit tests is the Arrange-Act-Assert pattern, also known as Triple AAA tests. Here’s a selection of articles illustrating this pattern:
- The Automation Panda’s Take on AAA tests
- Jay Cruz and the Three A’s of Unit Testing on Dev.to
- Leaning unit testing from Microsoft
and so on.
The gist is that every unit test should have three parts: _arrange_ your test with fixtues and elements to test, perform an _act_ on these fixtures that you wish to test, and then _assert_ the actual result of the action is the same as you expect.
This is a great pattern, except for one tiny issue: in some languages, there isn’t really an “assert”.
Increasingly, instead of the syntax
assert expectedCondition == actualCondition
we see something like
expect(expectedCondition).toBe(actualCondition)
This is true in JavaScript/TypeScript world, as well as in the Ruby world. In JS you have this pattern in libraries like Jest, while in Ruby the RSpec framework uses expect as well. This could lead to developers who never actually use an assert keyword in code. This leads the Triple AAA mnemonic to shambles.
Hence, here is the recipe Triple EEE tests:
- Enable test fixtures as needed
- Execute a step to be tested
- Expect a result and verify this happens.
A nice acronym, exactly expected.