The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.We need to design and develop a user interface through which users will interact with the new testing infrastructure.
Rather than in-line test results, I envision a 'testing block' or something similar that is displayed on a given issue page.
We also need a user interface for testing results on project pages. I anticipate re-purposing the 'automated testing' tab on existing project pages for this.
‘On Demand’ test triggers and User Interface
- In addition to the ‘automated’ jobs, there will be jobs which will need to be run based on user demand.
- User-initiated job triggers may be required in a few different locations:
- Project pages (for project/release level jobs)
- UI probably accessed via the ‘Automated testing’ tab
- Job examples:
- trigger simpletest/phpunit/behat tests for a given release
- Run through all patches for a given release and ensure they still apply
- Issue pages (for issue/patch level jobs)
- UI probably contained within a sidebar block
- Job examples:
- trigger simpletest/phpunit/behat tests for a patch
- Find all patches for a given release which would conflict with this patch (i.e. would need reroll if this is committed)
- Project pages (for project/release level jobs)
- We need both the User Interface design and backend coding for these triggers
- Actual triggering of a job should leverage the same triggering code as the ‘Automated’ test triggers
Here is the progress so far. For the files tables in issues:
And where "Add test" links to:
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | Screen Shot 2015-05-12 at 3.28.55 PM.png | 106.43 KB | drumm |
| #17 | Screen Shot 2015-05-12 at 3.29.13 PM.png | 45.5 KB | drumm |
Comments
Comment #1
jthorson commentedComment #2
MixologicAdding this META bluecheese design issue for references: they discuss how the appearance of inline things should be.
Im not sure we can avoid having inline results, as sometimes there is more than one patch at a time being worked on (two different architectural approaches, for example). We'd also want some historical results for older patches that did or didnt pass, so I think that data probably is best kept associated with the patches that are submitted inline as well.
Though I also see major value in having a testing block that gives an overall picture of the issue too...
Comment #3
jthorson commentedAlso to keep in mind, I migrated the simpletest testing information to a new 'Automated Testing' tab on projects, with the intention that we would further extend and leverage this tab as we enhance the infrastructure. Because it's provided by PIFT, assume we have full control and authority over any UI changes that we might want to land here (within the style guidelines, of course!).
Comment #4
MixologicRight on, I wasnt aware of that.. Is there an example of that somewhere? Im not sure which set of tabs you're referring to.
Comment #5
jthorson commentedOn any full project, it's the 'automated testing' link ... the one that takes you to node/[nid]/qa for that project.
Comment #6
MixologicAha. No wonder why I cant find it:
https://drupal.org/node/1449736
Maybe that policy needs to be reconsidered...
If a user who doesn't have full project permission submits a patch to a project, they ought to be able to get feedback for that patch.
Comment #7
jthorson commentedYup ... there's a couple of issues related to the QA tab ...
#2154351: Automated testing tab access for MaPS Suite module
#2136365: Testing status checkbox should be visible to all users (enable/disable based on permissions)
Comment #8
jthorson commentedComment #9
jthorson commentedComment #10
drummComment #11
drummComment #12
drummComment #13
drummComment #14
drummComment #15
drummComment #17
drummHere is the progress so far. For the files tables in issues:
And where "Add test" links to:
Comment #19
drummAdding screenshots to the issue summary.
Comment #25
drummI completed the branch retesting. I'm going to be bold and call this fixed. We can open up followup issues for anything specific we find.