PHPUnit problem - no error messages

user_272404 0
Viewed 10550

I've been trying to solve this problem for quite some time.

I have a simple PHPUnit test case with 2 tests. When I run it, I get this output:

PHPUnit 3.5.14 by Sebastian Bergmann.

.

So the first assertion runs, passes. The second assertion, however, causes some PHP error (exception or something), and PHPUnit just dies without any info about what could have gone wrong.

Here is my phpunit.xml:

<?xml version="1.0" encoding="UTF-8"?>

<phpunit backupGlobals="false"
    backupStaticAttributes="false"
    colors="false"
    convertErrorsToExceptions="true"
    convertNoticesToExceptions="true"
    convertWarningsToExceptions="true"
    processIsolation="false"
    stopOnFailure="true"
    syntaxCheck="false"
    bootstrap="bootstrap.php.cache"
>
    <testsuites>
        <testsuite name="Portal Test Suite">
            <directory>../src/OneSolution/Portal/*Bundle/Tests</directory>
        </testsuite>
    </testsuites>
</phpunit>

Setting syntaxCheck to true doesn't give any additional information about the error. However, it does print twice (before running any tests) that The filename, directory name, or volume label syntax is incorrect.

???

So, does anyone have any ideas what could I do to make PHPUnit report those error messages (the --verbose option didn't help either)?

EDIT: I've found out what has been causing the test to fail. There was a mistyped method name (I rely too much on code assist, I guess). However, this doesn't solve the main problem. Any warnings, errors or exception go unreported by PHPUnit.

symfony phpunit php
3 Answers

I used the --debug flag to pinpoint last test ran before output faded to nothingness. Then, I drilled my way down from that test to the method run before swallowing all output. Let's call it blackHole(). You can either move that call to its own test or quickly run it in the errant context

In my case, the problem was partly from blackHole(), and partly from its dependency. Changes had been made to blackHole(), but all their tests hadn't been run ever since. Then, its dependency had multiple errors (system-level/syntax errors like invalid interface implementation, most important. Then unexpected type supplied as argument). After correcting them, fixtures, all its tests passing etc, the original SUT started going through.

I believe PHPUnit reaches a point of no return when it encounters such low level errors outside the test scope. Or, it could have a small memory limit that a deeply nested exception can overflow, resulting in a crash. Since all output is buffered until run completion, nothing makes it out to the terminal

user_46788710
Related