Details for warnings are not displayed for --testdox

[thbley]

Q	A
PHPUnit version	10.2.3
PHP version	9.2.7
Installation Method	Composer

Summary

Using --testdox, details for warnings are not shown in output.

Current behavior

Using --testdox, details for warnings are not shown in output.

How to reproduce

php /tmp/bin/phpunit --testdox --testsuite feature --colors=always

Expected behavior

Using --testdox, details for warnings are shown in output.

Example outputs

Example output with --testdox (using non-phar composer version):

PHPUnit 10.2.3 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.2.7
Configuration: /var/www/phpunit.xml

W......W....                                                      12 / 12 (100%)

Time: 00:00.519, Memory: 4.00 MB

Tasks (TaskService\Tests\Feature\Tasks\Tasks)
 ✔ Url not found
 ✔ Login customer
 ✔ Login customer fail
 ✔ Task not found
 ✔ Get task
 ✔ Create task
 ✔ Update task
 ✔ Delete task
 ✔ Get current tasks
 ✔ Get completed tasks
 ✔ Process tasks from queue
 ✔ Import stream to click house

OK, but there are issues!
Tests: 12, Assertions: 116, Warnings: 2.

Example output without --testdox:

PHPUnit 10.2.3 by Sebastian Bergmann and contributors.

Runtime:       PHP 8.2.7
Configuration: /var/www/phpunit.xml

W......W....                                                      12 / 12 (100%)

Time: 00:00.495, Memory: 4.00 MB

1 test triggered 2 PHP warnings:

1) TaskService\Tests\Feature\Tasks\TasksTest::testDeleteTask
* Undefined property: stdClass::$application/json
  /var/www/tests/feature/Tasks/TasksTest.php:200

* Attempt to read property "schema" on null
  /var/www/tests/feature/Tasks/TasksTest.php:200

/var/www/tests/feature/Tasks/TasksTest.php:96

--

1 test triggered 1 warning:

1) TaskService\Tests\Feature\Tasks\TasksTest::testUrlNotFound
no validation for /foobar GET 404
/var/www/tests/feature/Tasks/TasksTest.php:211

/var/www/tests/feature/Tasks/TasksTest.php:31

OK, but there are issues!
Tests: 12, Assertions: 116, Warnings: 2.

phpunit.xml

<?xml version="1.0" encoding="utf-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="https://schema.phpunit.de/10.1/phpunit.xsd"
         bootstrap="tests/autoload.php"
         cacheResult="false"
         colors="true"
         displayDetailsOnTestsThatTriggerDeprecations="true"
         displayDetailsOnTestsThatTriggerErrors="true"
         displayDetailsOnTestsThatTriggerNotices="true"
         displayDetailsOnTestsThatTriggerWarnings="true"
>
  <testsuites>
    <testsuite name="unit">
      <directory>./tests/unit</directory>
      <directory>./tests/integration</directory>
    </testsuite>
    <testsuite name="feature">
      <directory>./tests/feature</directory>
    </testsuite>
  </testsuites>
  <php>
    <ini name="display_errors" value="On"/>
    <ini name="display_startup_errors" value="On"/>
  </php>
  <source>
    <include>
      <directory suffix=".php">./src</directory>
    </include>
    <exclude>
      <directory>./src/cli</directory>
      <directory>./src/vendor</directory>
      <file>./src/index.php</file>
      <file>./src/public.php</file>
    </exclude>
  </source>
</phpunit>

[sebastianbergmann]

This is not a bug, but currently the intended behaviour. Please understand that TestDox output is not intended to be a full replacement for the standard output and that not all information is displayed in TestDox output. This might change in the future.

[robertmarney]

As you are evaluating your decision on whether to revert to the previous functionality I thought I would provide some context on why my teams have ended up using testdox in CI and why the removal of the summary has hurt our developer experience.

• We build / maintain large enterprise code bases, some of the test suites have 5000+ tests.
• In the new world, when there is a failure we need to parse through the output to locate the details of the failing test (15000 lines)
• I appreciate we could go to the standard output, we settled into using textdox due to what happens when a core-dump or something more severe occurs (due to either code or CI hardware for that run), the textdox gives us a clear 'status' of where CI was able to execute to before the core dump occurred.

I know you have to consider the overall user base, but for what its worth my team would appreciate a return to the previous behavior. Either way. Thank you for the great tool.

[sebastianbergmann]

Superseded by #5518.