Closed (fixed)
Project:
Drupal core
Version:
11.x-dev
Component:
phpunit
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
17 Apr 2026 at 16:23 UTC
Updated:
8 Aug 2026 at 11:45 UTC
Jump to comment: Most recent
Problem/Motivation
If that's no longer needed, we can think of removing StubPDO.
Proposed resolution
Figure it out, and if confirmed deprecate the fixture class in 11.x, and remove in main.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3585476
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:
- 3585476-11.x
changes, plain diff MR !16399 - 3585476-remove-stubpdo changes, plain diff MR !15492
Comments
Comment #3
mondrakeComment #4
dcam commentedI can tell you based on my recent experience with stub objects that the StubPDO class looks entirely superfluous. Maybe there was a point to having it once, but not anymore. I looked over all of the changes and tried to figure out if there are any "gotchas" that might not be obvious. But the fact that they're all stubs inserted directly into constructors makes this pretty simple. It looks clear to me that we aren't doing anything important with these objects.
I grepped the code base and didn't find any more uses or mentions of StubPDO. So there's no concern there. Unfortunately, there are uses in contrib. See https://search.tresbien.tech/search?q=StubPDO. I hate to say it, but the class may need to be deprecated. I do feel we need to create a change record to document the change for anyone using the class, just to be friendly.
Comment #5
mondrakeNo big deal if we need to deprecate instead of straight remove.
Maybe let’s extend scope here to mark @internal all of the StubConnection classes, so we can be a little more free in the future?
What do you think?
Comment #6
mondrakeDone #5
Comment #7
mondrakeComment #8
mondrakeComment #9
dcam commentedI'm sorry that I didn't come back to this sooner.
Yes, I think that's a good idea too. These new changes look good to me.
Comment #12
catchCommitted/pushed to main, thanks!
Doesn't cherry-pick cleanly to 11.x so will need a backport MR.
Comment #14
mondrakeComment #15
dcam commentedThe 11.x MR is mostly identical to the one for main. The few additions in the 11.x MR are in line with the other changes to remove the use of
StubPDO. The Settings Tray failure is reproducible on the 11.x branch. The test discovery failures are caused by the problem described by #3612498: PhpUnitApiFindAllClassFilesTest not finding namespace errors. Therefore, the failures are not related to this MR. The backport looks good to me.Comment #17
catchCommitted/pushed to 11.x, thanks!