daily-email: add 2023-04-27
This commit is contained in:
parent
8ffafc444c
commit
37ac7cf277
22
src/content/daily-email/2023-04-27.md
Normal file
22
src/content/daily-email/2023-04-27.md
Normal file
|
@ -0,0 +1,22 @@
|
|||
---
|
||||
title: >
|
||||
TDD: write the test backwards
|
||||
pubDate: 2023-04-27
|
||||
permalink: >
|
||||
archive/2023/04/27/tdd-write-the-test-backwards
|
||||
tags:
|
||||
- automated-testing
|
||||
- test-driven-development
|
||||
---
|
||||
|
||||
When writing a test, something that I like to do is start by writing the first assertion first, and then work backwards.
|
||||
|
||||
My first assertion might be `self::assertTrue($result)`.
|
||||
|
||||
If I ran this test, it would fail because of the undefined `$result` variable - but it's clear to me what I need next by asking, "Where does `$result` come from?".
|
||||
|
||||
If I need to call a method on another class and get the result, I'll add it before the assertion. Then I repeat the process and ask, "What do I need for this to work?".
|
||||
|
||||
Maybe I need to create some users or content in the application for the class to query and return a result based on it, so I'll create those.
|
||||
|
||||
With this approach, I'm not making any assumptions about the test's prerequisites, and I usually find that I end up with cleaner and more focused tests.
|
Loading…
Reference in a new issue