uuid: - value: 92cbe949-7398-4e53-b101-11fd2140c868 langcode: - value: en type: - target_id: daily_email target_type: node_type target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7 revision_timestamp: - value: '2025-05-11T09:00:44+00:00' revision_uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 revision_log: { } status: - value: true uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 title: - value: | Write the test backwards created: - value: '2023-04-27T00:00:00+00:00' changed: - value: '2025-05-11T09:00:44+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2023/04/27/tdd-write-the-test-backwards langcode: en body: - value: |
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.
format: full_html processed: |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.
summary: null field_daily_email_cta: { }