uuid: - value: de42d5d4-29c1-4cd7-813a-1a1764f16a7b 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:01+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: 'Refactoring and Test-Driven Development' created: - value: '2025-02-10T00:00:00+00:00' changed: - value: '2025-05-11T09:00:01+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2025/02/10/refactoring langcode: en body: - value: |

To do test-driven development, you start by writing a test which, because you're testing code that doesn't exist, will fail.

The objective is to get the get the test to pass.

You want to write just enough code to get the test to pass.

It can be the simplest and naive code possible as long as it gets the tests to pass.

Once the test passes, you can refactor and change the code in any way you want.

This may be changing from a foreach loop to using a function like array_map or array_reduce, or splitting logic into separate classes.

You may refactor your refactor and decide that a name or approach isn't correct and change it.

You may split your code into service classes and then decide to use commands or actions.

You can make whatever changes you want as long as the tests continue to pass.

The implementation can change, but the outcome stays the same.

format: full_html processed: |

To do test-driven development, you start by writing a test which, because you're testing code that doesn't exist, will fail.

The objective is to get the get the test to pass.

You want to write just enough code to get the test to pass.

It can be the simplest and naive code possible as long as it gets the tests to pass.

Once the test passes, you can refactor and change the code in any way you want.

This may be changing from a foreach loop to using a function like array_map or array_reduce, or splitting logic into separate classes.

You may refactor your refactor and decide that a name or approach isn't correct and change it.

You may split your code into service classes and then decide to use commands or actions.

You can make whatever changes you want as long as the tests continue to pass.

The implementation can change, but the outcome stays the same.

summary: null field_daily_email_cta: { }