61 lines
2.5 KiB
Markdown
61 lines
2.5 KiB
Markdown
---
|
|
title: >
|
|
How not to break 36,000 websites
|
|
pubDate: 2023-09-16
|
|
permalink: >-
|
|
archive/2023/09/16/how-not-to-break-36-000-websites
|
|
tags:
|
|
- drupal
|
|
- php
|
|
- automated-testing
|
|
- test-driven-development
|
|
---
|
|
|
|
I've maintained the Override Node Options module for Drupal since early 2012.
|
|
|
|
I've maintained the Drupal 7 version and written new versions for Drupal 8 onwards.
|
|
|
|
At the time of writing, the module is used on at least 36,244 active Drupal websites.
|
|
|
|
I don't want to break 36,000 websites, and automated testing is my way of avoiding that.
|
|
|
|
I have three examples of how automated testing helped me when working on this module.
|
|
|
|
## Upgrading to Drupal 8
|
|
|
|
When writing the initial Drupal 8 version of the module, as I started re-writing a feature, the first thing I did was recreate the tests from the Drupal 7 version.
|
|
|
|
Then, I followed a test-driven development approach to get the test passing using the Drupal 7 code for reference.
|
|
|
|
When the whole test suite was in place and passing, I knew there was feature parity between the two versions.
|
|
|
|
## Resolving a large merge conflict
|
|
|
|
I was reviewing a feature request that had been open for some time, which included a large patch file with the code changes to implement it.
|
|
|
|
However, the patch no longer applied to the code, which caused various merge conflicts.
|
|
|
|
There were no additional tests within the patch, but I was able to use the existing tests to ensure the original functionality worked once the merge conflicts were resolved and there were no regressions caused by committing the patch.
|
|
|
|
I did later add tests for the new functionality, but without the original test suite, I would have likely not have accepted the patch and not committed the feature.
|
|
|
|
## Refactoring the code
|
|
|
|
A few years ago, a colleague and I wanted to refactor the module code to make it more maintainable and easier to work on.
|
|
|
|
Then, the module was used on around 30,000 websites, so this could have been risky.
|
|
|
|
However, we had the test suite to ensure the functionality still worked and that our refactors were successful.
|
|
|
|
If we broke something and introduced a regression, a test would fail, and we could fix it.
|
|
|
|
Following the release containing the refactored code, there were no reported issues or regressions from the community.
|
|
|
|
## Here's the thing
|
|
|
|
Automated testing is about providing confidence.
|
|
|
|
Confidence the software works as expected and is releasable, either to clients for custom software or consumers of open-source software.
|
|
|
|
With a passing test suite, you can add and change code with confidence and without worrying about breaking it.
|