oliverdavies.uk/content/node.1486a3bc-3bf6-436c-a6b9-1dc36dcb505d.yml

85 lines
4 KiB
YAML

uuid:
- value: 1486a3bc-3bf6-436c-a6b9-1dc36dcb505d
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:30+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: |
When should you run your tests?
created:
- value: '2023-10-23T00:00:00+00:00'
changed:
- value: '2025-05-11T09:00:30+00:00'
promote:
- value: false
sticky:
- value: false
default_langcode:
- value: true
revision_translation_affected:
- value: true
path:
- alias: /daily/2023/10/23/when-should-run-your-tests
langcode: en
body:
- value: |
<p>After my talk at DrupalCon, I was asked when you should run your tests.</p>
<p>Of course, if you're doing test-driven development, you have to run the tests as you work on them and have the red, green, refactor cycle as you work on the feature or bug fix.</p>
<p>If you're not doing TDD, I'd recommend running the whole test suite before you push your code to know it works before a peer review or to an environment for quality assurance or user-acceptance testing.</p>
<h2 id="what-about-ci-pipelines%3F">What about CI pipelines?</h2>
<p>As well as running tests manually, I'd add them to a CI pipeline, such as GitHub Actions, GitLab CI or Bitbucket Pipelines.</p>
<p>There, tasks can be run automatically each time a commit is pushed, so you don't need to rely on them being run manually.</p>
<p>If you're doing trunk-based development, you want the CI pipeline to run on every push to prevent regressions and ensure the tests continue to pass.</p>
<p>If you're working with feature branches and doing code review, run the tests as part of the merge or pull request so you know everything works as expected before the code is reviewed.</p>
<p>This answers the main "Does it work?" question, and allows the reviewer to focus on reviewing the code and suggesting improvements.</p>
<p>If the CI pipeline in the merge or pull request fails, it needs to be fixed before submitting it for review as there's no need to review the code before it changes to fix the pipeline.</p>
format: full_html
processed: |
<p>After my talk at DrupalCon, I was asked when you should run your tests.</p>
<p>Of course, if you're doing test-driven development, you have to run the tests as you work on them and have the red, green, refactor cycle as you work on the feature or bug fix.</p>
<p>If you're not doing TDD, I'd recommend running the whole test suite before you push your code to know it works before a peer review or to an environment for quality assurance or user-acceptance testing.</p>
<h2 id="what-about-ci-pipelines%3F">What about CI pipelines?</h2>
<p>As well as running tests manually, I'd add them to a CI pipeline, such as GitHub Actions, GitLab CI or Bitbucket Pipelines.</p>
<p>There, tasks can be run automatically each time a commit is pushed, so you don't need to rely on them being run manually.</p>
<p>If you're doing trunk-based development, you want the CI pipeline to run on every push to prevent regressions and ensure the tests continue to pass.</p>
<p>If you're working with feature branches and doing code review, run the tests as part of the merge or pull request so you know everything works as expected before the code is reviewed.</p>
<p>This answers the main "Does it work?" question, and allows the reviewer to focus on reviewing the code and suggesting improvements.</p>
<p>If the CI pipeline in the merge or pull request fails, it needs to be fixed before submitting it for review as there's no need to review the code before it changes to fix the pipeline.</p>
summary: null
field_daily_email_cta: { }