Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
We have currently an entry for simpletest as a component, but well, we are moving away from it.
Proposed resolution
Let's add a phpunit component and add a couple of people.
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#17 | 2808123-17.patch | 944 bytes | dawehner |
#11 | 2808123-11.patch | 776 bytes | klausi |
Comments
Comment #2
dawehnerLet's ask @alexpott, @berdir, @klausi whether they are fine with that.
Drupal.org already has that specific component.
Comment #3
dawehnerComment #4
alexpottI'm fine with this.
Comment #5
klausiYes, I'm also fine with this.
Comment #6
Wim LeersNice, thanks guys! While there are some rough edges still for sure, using
phpunit
instead ofrun-tests.sh
is so much better. Thanks for all your hard work on this!Comment #7
BerdirOk with me too.
Comment #9
dawehnerBack to RTBC
Comment #10
xjmNice, +1 for these maintainers. Thank you all!
I'm wondering if we should instead update it to be an entry for "Testing framework", since there are multiple related APIs, including BTB, JSTB, etc. and the test runner itself? This is in line with our idea to build maintainer teams within core, and could also help with some ambiguity with the specific component and what it includes.
Comment #11
klausiSure, a section for Testing Framework also works.
Note that we also had an abandoned "Testing" section in the file for topic maintainers, but I think it is a duplicate and we can consolidate that under the Testing Framework subsystem.
Note that I did not touch the entry for Simpletest module, I think we can leave that as is as long as we have the module. Just in case people search for simpletest in the file.
We don't mention the word "PHPUnit" anywhere in the file, but that should also be OK for now, we will have a special place for the PHPUnit initiative anyway #2808121: Add PHPUnit initiative to MAINTAINERS.txt.
Comment #12
xjmWell, so the "Testing" section is supposed to be for the Testing topic maintainer, which is a different role than Subsystem maintainer that has to be approved by Dries. (The idea being that the topic maintainers are each responsible for a core gate.) So we might have different maintainers for APIs for testing, vs. the person responsible for maintaining testing best practices across core (in the same way that Bojhan and yoroy maintain our usability best practices).
It could also be worth removing the redundant-ish simpletest entry, depending on what alexpott and Berdir think. (Otherwise we can also do that once we actually deprecate it entirely; I can see either way.) :)
Comment #13
dawehnerIt is a tricky question, because well, there might be also tests written in javascript at some point. Those should have its own subsystem I guess?
What about just making it really obvious:
Comment #14
xjmAlso see #2786145: Clarify how multiple maintainers share a role.
Ideally I think our PHPUnit-based tests, our legacy SimpleTests, our test runner, and maybe even future hypothetical qunit tests would all be maintained by a single team of people, even if some of those people individually said "I am SO not doing anything with SimpleTest" or "JS what?"
OTOH @dawehner's suggestion is the minimal scope to add the entry. I just am trying to encourage each governance change to MAINTAINERS.txt go in the direction we want of fewer components and more teams, rather than away from it.
Comment #15
dawehnerSo you argue certainly more in the direction of the patch? I've adapted it and removed the Simpletest side of things.
On top of that though I'm wondering whether this discussion: topic maintainer vs. subsystem maintainer actually opens up a different question. Conceptually tests
are in parallel to the actual files which produce the value. Given that its not an integral part of the system, and it belongs more into the topic region. This also again opens
up the wormhole of actually having the testing framework be its own package.
PS: I still think it would be beneficial to categorize comments from committers to know what are discussions and what are decisions.
Comment #16
xjm@dawehner, to me the direction of the current patch makes sense (if we undo the removal of the Testing topic which is actually sort of an out of scope governance change), but it matters more what the maintainers for the proposed component think than what I think.
If I make a decision, I'll mark something Needs work. If I'm not sure and just want to propose a suggestion, I'll mark it Needs review. (I'm not sure how any of my extremely wishy-washy "I think" and "I wonder" and "I can see either way" and "it could be worth" could be construed as a decision or even a recommendation, but I guess I'm relying a lot on subtleties of language and tone that might not be very clear in text or the same across languages.) :)
Does an issue exist already for the idea of making the testing framework its own component? It is a can of worms for sure, and I'm not sure we could change it in 8.x even if we all agreed it was the best choice and solved every concern, but it keeps coming up in a lot of different contexts so it seems like it's worth discussing and exploring somewhere in the queue. Maybe the ideas queue.
Comment #17
dawehnerHere is the patch file which removes the simpletest component.
I don't think so, well, I just fear that this further defers work on the BTB conversions.
Comment #18
xjm#17 looks good to me, if the other maintainers for the component are comfortable with it.
Comment #19
klausiGood enough for me.
Comment #20
klausiComment #21
alexpottCommitted and pushed 1b5802d to 8.3.x and 86a61e2 to 8.2.x. Thanks!