The issue originally was opened because the testbot doesn't return errors properly, see https://qa.drupal.org/pifr/test/632778 -- the error message is missing; the line number is the method not the actual assert. (#1 has a screenshot too.)

However, as msonnabaum refused to fix this it's clear that our PHPunit integration is unmaintained. We need someone who is willing to fix the technical issues at least, ideally the community issues as well (documentation, presentations, awareness etc. all missing).

CommentFileSizeAuthor
#1 Selection_140.png18.35 KBchx

Comments

chx’s picture

chx commented
StatusFileSize
new Selection_140.png18.35 KB
msonnabaum’s picture

msonnabaum commented
Assigned: msonnabaum » Unassigned
chx’s picture

chx commented
Title: Testbot does not return PHPunit fails properly » Find a PHPunit maintainer
Component: simpletest.module » other
Category: bug » task
Priority: Normal » Critical
chx’s picture

chx commented
Issue summary: View changes

Updated issue summary.

catch’s picture

catch
he/him
Primary language English
commented

Opening an issue assigned to someone else is not on. Nor is changing the title/priority in this way.

Also the correct fix for this is for the test bot to directly run unit tests prior to simpletest and bail out if they fail (similar to the applies/lint checks now). Rather than running them circuitously via simpletest as it currently does.

chx’s picture

chx commented

Removing the simpletest integration completely is another way of fixing it for sure. First we patch bot then we remove that from core. Works for me.

chx’s picture

chx commented

> Opening an issue assigned to someone else is not on.

Erm, why not? I know two ways of getting attention of a maintainer, a) marking the issue major/critical b) assigned. So, why not?

catch’s picture

catch
he/him
Primary language English
commented
Title: Find a PHPunit maintainer » Testbot does not return PHPunit fails properly
Category: task » bug
Priority: Critical » Normal

We could leave the simpletest integration in if we wanted to - just need an option to skip those tests from CLI / run them only from the UI or etc. Even running them twice for a while would not be a serious issue.

An issue needs to be assigned to a maintainer only if it requires feedback from them. Either 'no idea how to fix it', or 'two ways to fix it do you have a preference' or similar.

Having your name in MAINTAINERS.txt for a component != volunteering to fix every single bug in a component that comes up. Clearly #4 is using a different interpretation since there's nothing here that explicitly needs msonnabaum's input whatsoever.

catch’s picture

catch
he/him
Primary language English
commented
Issue summary: View changes

Updated issue summary.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

quietone’s picture

quietone commented
Issue summary: View changes
Status: Active » Closed (duplicate)
Issue tags: +Bug Smash Initiative
Related issues: +#2769211: assertion messages and line numbers in PHPUnit tests are not reported by run-tests.sh or Simpletest UI

This looks like very much like a duplicate of #2769211: assertion messages and line numbers in PHPUnit tests are not reported by run-tests.sh or Simpletest UI which is now closed. The test bot does reports the error message and the line number of the failed assertion.

Closing this as a duplicate. As always, if this is incorrect please reopen and clarify what still needs to be done here.