Risky / No assertions check hinders use of Hamcrest

[ascii-soup]

Q	A
PHPUnit version	6.2.3
PHP version	7.0.10
Installation Method	Composer

Using the hamcrest assertions library (https://github.com/hamcrest/hamcrest-php) with PHPUnit 6 is proving tricky. All tests are being marked as Risky due to them not having any assertions.

Graze's hamcrest-test-listener (https://github.com/graze/hamcrest-test-listener) has added to the assertion count previously by using a test listener and calling

$test->addToAssertionCount($x)

for the number of Hamcrest assertions made in the test.

However, in PHPUnit 6 (and perhaps 5, I've not used 5) this does not work because the risky check happens before the endTest() method in the listeners is called.

I had considered using assertPostConditions() but this would be limited by the single inheritance model - for example, Mockery provides a trait to verify its post conditions in that method, which could conflict with the usage for the above purpose.

Is there another unobtrusive way that this could be performed using the current PHPUnit 6 feature set?

[sebastianbergmann]

If you do not want the risky test check then simply disable it.

[ascii-soup]

But the risky test check is useful, in case I have forgotten to use any assertions. I think it would be nice to support other assertion libraries other than PHPUnit's - as many people have done in the past - whilst also benefiting from the risky tests feature in PHPUnit.

Can this be done?

Or will that not be a goal of PHPUnit going forward?

[courtney-miles]

I can only assume this has been declined because listeners are not intended to be used to modify the outcome of tests.

This may be why Mockery ditched its use of listeners for performing this tasks and adopted a trait instead.

I had considered using assertPostConditions() but this would be limited by the single inheritance model - for example, Mockery provides a trait to verify its post conditions in that method, which could conflict with the usage for the above purpose.

Overriding \PHPUnit\Framework\TestCase::assertPostConditions() is what I adopted. Here's a simple example for others reference.

use Hamcrest\MatcherAssert;
use PHPUnit\Framework\TestCase;

class MyTest extends TestCase
{
    protected function assertPostConditions()
    {
        $this->addToAssertionCount(MatcherAssert::getCount());
        MatcherAssert::resetCount();

        parent::assertPostConditions();
    }

    // ...
}

If you are using \Mockery\Adapter\Phpunit\MockeryPHPUnitIntegration, then the the following is example of how to resolve the conflicts over redefining assertPostConditions().

use Hamcrest\MatcherAssert;
use Mockery\Adapter\Phpunit\MockeryPHPUnitIntegration;
use PHPUnit\Framework\TestCase;

class MyTest extends TestCase
{
    use MockeryPHPUnitIntegration {
        MockeryPHPUnitIntegration::assertPostConditions as mockeryAssertPostConditions;
    }

    protected function assertPostConditions()
    {
        $this->addToAssertionCount(MatcherAssert::getCount());
        MatcherAssert::resetCount();

        self::mockeryAssertPostConditions();
    }

    // ...
}

It is tedious to have to do this for every test, so I extend \PHPUnit\Framework\TestCase as MyTestCase with the above logic, and then ensure all my Tests extended MyTestCase instead of \PHPUnit\Framework\TestCase.

[doctor-beat]

+1

This last answer is the only correct answer and should in fact be added to the hamcrest-php documentation!