Defining boundaries between custom Drupal modules
I recently made a change to a Drupal project with several custom modules.
As part of the change, there was a method that was no longer being used, so I went ahead and removed it.
There were no tests for this part of the codebase, and the existing tests were still passing.
My change was successfully finished and deployed, including removing the unused method.
A few days later, we noticed cron jobs were no longer running on the website.
The method I'd removed was attempting to be called from within a different module.
Because it no longer existed, it was causing an error and stopping the cron job from running successfully.
When I re-added the method, the cron jobs worked again.
There were no dependencies set in either module's .info.yml file, though that would only prevent you from uninstalling either module.
It wouldn't prevent me from deleting code used by another module.
Here's the thing
This is why I've been experimenting with architectural testing. To ensure that modules only use their own code and to start enforcing layers within each module.
Then, if I had the same situation again, I'd know straight away that there was an issue and not have to wait for the bug to be deployed to production.
- Oliver
