uuid: - value: 526f1b74-c255-4dd3-ba7a-5d529545d01d langcode: - value: en type: - target_id: daily_email target_type: node_type target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7 revision_timestamp: - value: '2025-05-11T08:59:58+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: 'Automated tests reduce debugging time' created: - value: '2025-04-01T00:00:00+00:00' changed: - value: '2025-05-11T08:59:58+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2025/04/01/debugging langcode: en body: - value: |
In my talk about automated testing and test-driven development, I speak about a custom module I wrote for a client's Drupal project.
It was to integrate with a third-party job application system that they would log into and enter information via a form (similar to Drupal's node forms) that they wanted to appear on the Drupal website.
Once submitted, the system would send a POST request to an endpoint provided by the custom module. The module would process it and create the job node with the appropriate field values.
I wrote automated tests and did test-driven development.
Everything worked great for a few weeks or months.
Later, we had a message from the client saying the integration was broken and we needed to fix it.
I don't think I'd worked on this module for a while, but I was concerned that a Drupal core update or another change could have caused a regression.
The first thing I did was run the tests I'd written and verify they still passed, which they did.
This confirmed that as long as the data was being sent in the expected format, the node would be created and the integration would work.
Due to an upstream issue, the data was no longer in the expected format, which meant the node could not be created.
Once it was fixed, everything started working again.
My debugging time was practically zero as I was able to rely on my tests and that they were still passing.
I could confidently tell the client that the issue wasn't with our code and must've been an third-party issue.
Writing tests takes some time, but having tests saves time.
format: full_html processed: |In my talk about automated testing and test-driven development, I speak about a custom module I wrote for a client's Drupal project.
It was to integrate with a third-party job application system that they would log into and enter information via a form (similar to Drupal's node forms) that they wanted to appear on the Drupal website.
Once submitted, the system would send a POST request to an endpoint provided by the custom module. The module would process it and create the job node with the appropriate field values.
I wrote automated tests and did test-driven development.
Everything worked great for a few weeks or months.
Later, we had a message from the client saying the integration was broken and we needed to fix it.
I don't think I'd worked on this module for a while, but I was concerned that a Drupal core update or another change could have caused a regression.
The first thing I did was run the tests I'd written and verify they still passed, which they did.
This confirmed that as long as the data was being sent in the expected format, the node would be created and the integration would work.
Due to an upstream issue, the data was no longer in the expected format, which meant the node could not be created.
Once it was fixed, everything started working again.
My debugging time was practically zero as I was able to rely on my tests and that they were still passing.
I could confidently tell the client that the issue wasn't with our code and must've been an third-party issue.
Writing tests takes some time, but having tests saves time.
summary: null field_daily_email_cta: { }