117 lines
5.4 KiB
YAML
117 lines
5.4 KiB
YAML
uuid:
|
|
- value: 39db6489-2e23-4cb3-a0be-a4e78a2e9142
|
|
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:26+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: |
|
|
Partial mocking
|
|
created:
|
|
- value: '2023-11-23T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:26+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2023/11/23/partial-mocking
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>Today, I wrote a test whilst fixing a bug in some legacy custom Drupal code.</p>
|
|
|
|
<p>The code is for a custom block, which can be configured using user-defined settings - including a link URL.</p>
|
|
|
|
<p>In this case, if the link was null (one hadn't been provided), the link was generated to the home page instead of the desired destination.</p>
|
|
|
|
<h2 id="my-first-attempt">My first attempt</h2>
|
|
|
|
<p>There was a combination of settings needed to replicate the bug, such as the current site language, the node type the block was placed on and, of course, an empty link URL.</p>
|
|
|
|
<p>Because the block uses the current route to get the current node, my first attempt to test this was to use a browser/functional test.</p>
|
|
|
|
<p>That failed quickly after having to enable various other custom modules due to dependencies and to add and configure unrelated configuration settings.</p>
|
|
|
|
<h2 id="my-second-attempt">My second attempt</h2>
|
|
|
|
<p>My second attempt used kernel/integration tests, but as there's no <code>setParameter()</code> method on the route matcher I could use in the test, I'd need to rely on mocking.</p>
|
|
|
|
<p>In a unit test, everything needs to be mocked, but a kernel test allows me to be more selective, only mock what I need, and use the real services for everything else - a.k.a. partial mocking.</p>
|
|
|
|
<h2 id="the-result">The result</h2>
|
|
|
|
<p>I replicated the bug by setting the default and current languages, creating a mock language manager, creating a node of the required type and returning it from a mocked route match.</p>
|
|
|
|
<p>Everything else remained the same.</p>
|
|
|
|
<p>Then, I fixed the bug and used a data provider to provide different variables into the test so each use case was covered.</p>
|
|
|
|
<h2 id="here%27s-the-thing">Here's the thing</h2>
|
|
|
|
<p>The whole test file is 129 lines and would have been much more if I'd had to replicate all the configuration in a functional test or mock everything in a unit test.</p>
|
|
|
|
<p>An integration test with partial mocking was ideal in this case, as it gave me the most flexibility to test what I needed whilst keeping the code simple.</p>
|
|
|
|
<p>Whilst I'm aware of over-using mocks, this was an ideal situation to use them.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>Today, I wrote a test whilst fixing a bug in some legacy custom Drupal code.</p>
|
|
|
|
<p>The code is for a custom block, which can be configured using user-defined settings - including a link URL.</p>
|
|
|
|
<p>In this case, if the link was null (one hadn't been provided), the link was generated to the home page instead of the desired destination.</p>
|
|
|
|
<h2 id="my-first-attempt">My first attempt</h2>
|
|
|
|
<p>There was a combination of settings needed to replicate the bug, such as the current site language, the node type the block was placed on and, of course, an empty link URL.</p>
|
|
|
|
<p>Because the block uses the current route to get the current node, my first attempt to test this was to use a browser/functional test.</p>
|
|
|
|
<p>That failed quickly after having to enable various other custom modules due to dependencies and to add and configure unrelated configuration settings.</p>
|
|
|
|
<h2 id="my-second-attempt">My second attempt</h2>
|
|
|
|
<p>My second attempt used kernel/integration tests, but as there's no <code>setParameter()</code> method on the route matcher I could use in the test, I'd need to rely on mocking.</p>
|
|
|
|
<p>In a unit test, everything needs to be mocked, but a kernel test allows me to be more selective, only mock what I need, and use the real services for everything else - a.k.a. partial mocking.</p>
|
|
|
|
<h2 id="the-result">The result</h2>
|
|
|
|
<p>I replicated the bug by setting the default and current languages, creating a mock language manager, creating a node of the required type and returning it from a mocked route match.</p>
|
|
|
|
<p>Everything else remained the same.</p>
|
|
|
|
<p>Then, I fixed the bug and used a data provider to provide different variables into the test so each use case was covered.</p>
|
|
|
|
<h2 id="here%27s-the-thing">Here's the thing</h2>
|
|
|
|
<p>The whole test file is 129 lines and would have been much more if I'd had to replicate all the configuration in a functional test or mock everything in a unit test.</p>
|
|
|
|
<p>An integration test with partial mocking was ideal in this case, as it gave me the most flexibility to test what I needed whilst keeping the code simple.</p>
|
|
|
|
<p>Whilst I'm aware of over-using mocks, this was an ideal situation to use them.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|