PHPUnit silently ignores the return value on a void method

[morozov]

Q	A
PHPUnit version	8.1.0
PHP version	7.3.4
Installation Method	Composer

Consider the following test:

declare(strict_types=1);

use PHPUnit\Framework\TestCase;
use PHPUnit\Framework\MockObject\MockObject;

class Doer
{
    public function doStuff() : void
    {
    }
}

class PHPUnitTest extends TestCase
{
    public function test() : void
    {
        /** @var Doer|MockObject $doer */
        $doer = $this->createMock(Doer::class);
        $doer->expects($this->any())
            ->method('doStuff')
            ->willReturn(true);

        $this->assertNull($doer->doStuff());
    }
}

The test passes:

PHPUnit 8.1.0 by Sebastian Bergmann and contributors.

Testing PHPUnitTest


Time: 69 ms, Memory: 8.00 MB

OK (1 test, 1 assertion)

The test shouldn't pass since the willReturn(true) behavior cannot be achieved.

Fixing this issue could help keep existing tests up to date when the return value of a method is changed from something to void.

[sebastianbergmann]

Thank you for bringing this to my attention. Unfortunately, this is not as easy to fix as it should be or as one might assume it is.

In your example, the call to willReturn() should trigger an exception because a return value is about to be configured for doStuff() which is void. This exception would then be used by PHPUnit to report a warning that there is something wrong with regard to test double configuration.

However, inside willReturn() we do not have the information available for which method a return value is configured. And since we do not know which method is being configured we do not know whether that method is void or not and if its configuration is possible. This was okay back in 2006 when the functionality was originally created and return type declarations, for instance, did not exist. Today it is not good enough anymore.

TL;DR Fixing this issue very likely requires a substantial refactoring of the runtime (not the code generation) part of PHPUnit's test double functionality.

[morozov]

Thank you for the explanation. I understand the problem.

[sebastianbergmann]

This is a special case of #3122.