From 37ac7cf2778ac55301fcf98addd7d3fa94e01a0f Mon Sep 17 00:00:00 2001 From: Oliver Davies Date: Thu, 27 Apr 2023 20:43:56 +0100 Subject: [PATCH] daily-email: add 2023-04-27 --- src/content/daily-email/2023-04-27.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 src/content/daily-email/2023-04-27.md diff --git a/src/content/daily-email/2023-04-27.md b/src/content/daily-email/2023-04-27.md new file mode 100644 index 00000000..02bd582a --- /dev/null +++ b/src/content/daily-email/2023-04-27.md @@ -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.