Problem/Motivation
There are no clear guidelines when it comes to deciding how to provide test coverage for a new core feature or a bug fix.
Proposed resolution
As part of #3627430: [META] Adopt the Test Pyramid approach, we discussed adding an example (hidden) module collecting all the best practices for both production and test code, with inline documentation explaining the rationale behind the various choices. Both humans and AI agents can benefit from this.
Once this is finalized, core modules will be adapted to follow this template.
The module would be living documentation, updated whenever best practices change to keep reflecting the state of the art.
Remaining tasks
- Validate the proposed solution
- Post an MR
- Review it
User interface changes
None
Introduced terminology
None
API changes
None
Data model changes
None
Release notes snippet
TBD
Issue fork drupal-3627449
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
plachComment #4
plachComment #5
smustgrave commentedThink this probably belongs in https://www.drupal.org/project/examples
-1 to adding to core directly though. If the goal is to help agents then think the Agents.md file could be helped.
Comment #6
quietone commentedI still have more to read up about this on the parent issue. But, so far, I don't think core is the place for an example module. There is also the possibility to add this within the Coding Standards. There is an issue over there to discuss adding Drupal best practices to the standards.
Comment #7
smustgrave commentedIf the goal is to help AI best practices maybe they can make it a requirement to download the contrib module but agree don't think belongs in core.
Comment #8
plach@quietone @smustgrave
The reason why I'm suggesting a core example module, instead of relying on the canonical examples project, is that, as a human, I tend to rely a lot on core modules themselves as examples. However, core modules are not always consistent in their implementation of best practices, it heavily depends on their "state of maintenance" within core and how often they change. This makes it hard to figure out which is the best source for inspiration. Moreover, in case of discrepancies, it's not clear which module "is right". My goal would be to ensure that all core modules follow a fixed pattern, at the least in their key parts, and that we have an official "source of truth" that can settle the debate of how a certain bit of logic should be implemented – and document the rationale.
I don't think the examples module is the right fit for this specific use case, because it's not readily available in the core codebase for anyone to look at. People may not even know it exists, whereas a core example linked from the README would be much more likely to be discovered.
Anyway, even if we end up not doing this, I'd still like to keep the issue around until we have a set of documented guidelines on how to author tests and how to make your code more unit testable – I'm going to open a separate issue for that shortly. For now the goal has been to be able to open a MR and post the examples I demoed during this session, so that we have some actual code to discuss.
Btw, would you mind expanding on why you think having an example module in core is not desirable?
Comment #9
smustgrave commentedThink I understand your goal and I too will also tend to look at existing modules for how to achieve something.
For me least what you’re describing sounds exactly the kind of thing for contrib though or coding standard docs vs a core module.
Also sounds like what https://www.drupal.org/project/examples was intended for, though it may need some love. It’s actually a shame that’s not a priority
And as mentioned helping AI, as I saw in the parent one of the tasks was to update AI best practices, downloading a contrib module seems like something it can do.
Not sure which Id prefer more better documentation or an updated examples module maybe 1a and 1b. But just can’t see the need for core to ship with an examples module
And may be completely irrelevant but did think of this https://www.drupal.org/node/3618953
I’m also just a Submaintainer on core so my opinion doesn’t have as much weight so tagging for big brains
Comment #10
smustgrave commentedAnd just to make sure I'm not coming off wrong I am a -1 but also if the consensus turns out to be yes I'm happy then too :)
Comment #11
plach@smustgrave
Thanks for the clarifications!
Here's the ticket to discuss the guidelines/best practices themselves: #3627934: Promote unit testability via code best practices.
Comment #12
plach@smustgrave:
AI is not the key focus of the initiative, although agents will definitely benefit from a faster test suite and a better organized codebase. The AI-related item in the parent issue is to ensure that the AI best practices reflect the outcome of these discussions. At the moment, those practices recommend not using unit tests, whereas increasing their use is a cornerstone of the Test Pyramid proposal.
Comment #13
larowlanPlaying devils' advocate, rather than shipping a hidden example module, could we instead work to improve what core does and add a docs tag e.g. @best-practice on things that meet it and then that can be referenced as 'do it this way'. My concern is that the example module might get out of date.
Comment #14
smustgrave commentedOhhh I like that idea a lot. Easy to find for humans and I have to imagine easy to find for AI.
Comment #15
quietone commentedIf we add '@best-practice' we also need an issue for the API module to make sure it displays it correctly,
The down side is that we could have '@best-practice' all over the code, in multiple places for the same concept. How would a core dev know when to add the tag or not?
Comment #16
plachI initially loved the
@best-practicesuggestion, but on second thought, I think the same concern applies to it as to the example code: what if it becomes obsolete? You'd then be back to different parts of core disagreeing on what a best practice is—and, even worse, they'd both claim to be implementing a best practice. Super confusing.OTOH, a core example module would be the central place for such an authoritative role: we could have a gate saying that you can't introduce new ways of doing things without updating the example/template code. Any disagreement would then be automatically resolved in favor of that.
I'm not a fan of the idea of a hidden example module lying around in core either, but honestly I cannot give a good reason why that's a bad idea, other than "I don't like it" :)
(and, of course, that we already have the examples project, which unfortunately is not in core ;)
I created an issue in the examples project queue referencing this. Hopefully we'll get some useful perspective :)
Comment #17
plachComment #18
avpadernoEverything committed in a repository can become obsolete. Moving a module from a project to another one does not make that less likely. That is already evident with the .api.php files that come with Drupal core: Many examples of hook implementations had to be updated because the hook parameters changed, the hook was invoked in different cases, or a hook name changed.
Comment #19
avpadernoA hidden module is not listed as installable module; therefore, it would not be probably noticed. If that module should not be installed on a production site, there is a chance it would still be copied because nobody notices it from the user interface.