phpspec / prophecy-phpunit

Integrating Prophecy in PHPUnit test cases

Prophecy

Prophecy PhpUnit integrates the Prophecy mocking library with PHPUnit to provide an easier mocking in your testsuite.

Installation

Prerequisites

Prophecy PhpUnit requires PHP 7.3 or greater. Prophecy PhpUnit requires PHPUnit 9.1 or greater. Older versions of PHPUnit are providing the Prophecy integration themselves.

Setup through composer

composer require --dev phpspec/prophecy-phpunit

You can read more about Composer on its official webpage.

How to use it

The trait ProphecyTrait provides a method prophesize($classOrInterface = null) to use Prophecy. For the usage of the Prophecy doubles, please refer to the Prophecy documentation.

Below is a usage example:

<?php

namespace App;

use PHPUnit\Framework\TestCase;
use Prophecy\PhpUnit\ProphecyTrait;
use App\Security\Hasher;
use App\Entity\User;

class UserTest extends TestCase
{
    use ProphecyTrait;

    public function testPasswordHashing()
    {
        $hasher = $this->prophesize(Hasher::class);
        $user   = new User($hasher->reveal());

        $hasher->generateHash($user, 'qwerty')->willReturn('hashed_pass');

        $user->setPassword('qwerty');

        $this->assertEquals('hashed_pass', $user->getPassword());
    }
}

prophecy-phpunit's Issues

phar release as phpunit extension?

Hi,

Since PHPUnit 10 is dropping this repo is back to live. But unfortunately, this reintroduces an issue that we had in phpDocumentor for years. prophecy is using some of our core libraries which is perfectly plausible but this causes issues when testing those libraries with our preferred mocking framework ❤️

We were facing 2 issues:

• circular dependencies, preventing us from installing PHPUnit via composer and prophecy.
• PHP loads classes by namespace only once. Which caused all kinds of odd issues during our unit tests. Like testing the wrong subject.

A few releases ago PHPUnit started shipping a scoped phar which recompiles the PHPUnit extensions into a PHPUnit specific namespace. This awesome move finally gave us the option to install PHPUnit without any hacks and issues. Stabilizing our ci pipeline.

Now PHPUnit 10 will drop build-in prophecy shipping these issues will most likely come back. So I started investigating a workaround, which I found. PHPUnit supports loading extensions from phar files. together with phar.io this would be a very nice solution to install prophecy as a PHPUnit extension in a scoped phar.

How it works

Following the example extension I could create a phar file which is loaded by PHPUnit. I could provide an example phar, but it is useless right now because PHPUnit still ships prophecy so classes will conflict. The "only" thing to do would be to create a manifest and set up the scripts to be able to build a phar for each new release.

If you understand my problem, I would like to hear if you are interested in some GitHub action scripts that will automate the process of creating a phar for each release.

Disclaimer
I'm not aware of any other projects facing this issue, but I think in general shipping development tools in isolation makes sense. phar.io is under development. But I think this could be the new revolution in PHP dependency management. Since it solves a number of issues that cannot be solved by composer. Like the described issues above. But also for applications that are not able to upgrade dependencies but would like to move forward with their toolchain to keep up.

Besides that, I do fully understand that you might not have the time to maintain the creation of the phar. That's why I'm offering my support for just this part.

Update description

I suggest to update the description of the project as well as in composer.json, as the project no longer provides a test case, but a trait:

Project

composer.json

prophecy-phpunit/composer.json

Line 3 in 049638b

"description": "PhpUnit test case integrating the Prophecy mocking library",

PHPUnit 10 Support

PHPUnit 10 was released 5 days ago
https://github.com/sebastianbergmann/phpunit/releases/tag/10.0.0

It's not possible to upgrade because of dependency in composer.json "require": { ... "phpunit/phpunit":"^9.1" ... }
https://github.com/phpspec/prophecy-phpunit/blob/master/composer.json#L19

Could this be better implemented as a PHPUnit extension?

PHPUnit 11 deprecations

I've already opened #59 + phpspec/prophecy#616 to allow PHPUnit 11 compatibility, but I've already found that the ProphecyTrait triggers deprecations in that case. It triggers 2 deprecations for each test execution, so that A LOT of noise, especially if data providers are involved.

As already (wrongly) reported in sebastianbergmann/phpunit#5693 (comment),

[...] the causes are the @postCondition and @after annotations here:

• prophecy-phpunit/src/ProphecyTrait.php

  Lines 57 to 60 in 29f8114

  	/**
  	* @postCondition
  	*/
  	protected function verifyProphecyDoubles(): void

• prophecy-phpunit/src/ProphecyTrait.php

  Lines 75 to 78 in 29f8114

  	/**
  	* @after
  	*/
  	protected function tearDownProphecy(): void

Those annotations can be replaced by attributes since PHPUnit 10.0.0, or you can replace it with using the assertPostCondition and tearDown methods.

So, I'm asking, how should we proceed? I see 3 possibilities:

• we switch to the assertPostCondition and tearDown methods, so that we don't drop support for older versions (but we mess with the inheritance chain of those methods, and the user could inadvertently deactivate that code path)
• we switch to attributes, dropping support for PHPUnit 9
• we do a mix, adding the methods but invoking the sub-methods only for PHPUnit 9, leaving the rest to the attributes

WDYT? ping @stof

New release for PHP 8

Support for PHP 8 has been added in #25.
If there's no blocking issues, a new (patch?) release should be tagged now that PHP 8 is GA.

Move this to PHPUnit?

As of sebastianbergmann/phpunit@c512c3e, the branch for PHPUnit 4.4 "bundles" the ProphecyTestCase class (as well as Prophecy itself, of course). This makes it even easier to get started with using Prophecy from PHPUnit.

However, the more I think about it -- especially with regards to issues such as the one discussed in #6 -- the more I tend to wanting the code of ProphecyTestCase inside PHPUnit_Framework_TestCase directly.

What do you think, @everzet? I want to have a rock solid, painless (out-of-the-box), and complete (expectation counter) Prophecy experience for PHPUnit users as soon as possible.

Inconsistent casing

To be consistent with the PHPUnit project, it would be nice if this project used PHPUnit instead of PhpUnit in the namespaces and documentation.

Mark `v2.0.0` as `latest release` on GitHub

Currently, GitHub says 1.1.0 is the latest release.

Argument shortcut method on the TestCase

What would you think about adding an arg() method or arg property on the test case that would return a Prophecy\Argument instance ?

I did it in https://github.com/hautelook/frankenstein#prophecy-arguments , but maybe it would be useful for everyone using prophecy-phpunit.

Release for not-deprecated fix

Hey :)

Could you release a new version for the @not-deprecated fix from #52 ?

If I can do anything to help you, please tell me :)

Unable to install on PHP 8.2.1?

Problem 1
- phpspec/prophecy v1.15.0 requires php ^7.2 || ~8.0, <8.2 -> your php version (8.2.1) does not satisfy that requirement.
- phpunit/phpunit 9.5.20 requires phpspec/prophecy ^1.12.1 -> satisfiable by phpspec/prophecy[v1.15.0].
- phpunit/phpunit is locked to version 9.5.20 and an update of this package was not requested.

You can also try re-running composer require with an explicit version constraint, e.g. "composer require phpspec/prophecy-phpunit:*" to figure out if any version is installable, or "composer require phpspec/prophecy-phpunit:^2.1" if you know which you need.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

Tag a new release

Is there anything that prevents a new release to be tagged? I will release PHPUnit 9.1 on Friday, April 3, 2020, and it would be great if the new version would be available then.

phpunit 10 support

Unable to install a recent version of the package alongside phpunit 10:

  Problem 1
    - phpspec/prophecy-phpunit v2.0.0 requires php ^7.3 -> your php version (8.1.12) does not satisfy that requirement.
    - phpspec/prophecy-phpunit v2.0.1 requires phpunit/phpunit ^9.1 -> found phpunit/phpunit[9.1.0, ..., 9.6.3] but it conflicts with your root composer.json require (^10).
    - Root composer.json requires phpspec/prophecy-phpunit ^2 -> satisfiable by phpspec/prophecy-phpunit[v2.0.0, v2.0.1].

php

PhpUnit 10 support

Hello,

When could we expect new patch with PhpUnit 10.x support? Thank you!

cc @stof

Migrate to GH Actions ?

I'm looking to create a PR to address Yoast/PHPUnit-Polyfills#62 and just noticed that the CI is still on travis-ci.org, which (for the most part) is no longer functional.

@stof Would it be okay if I migrate the CI checks to GitHub Actions to get them running again ?

Mocks do not fail immedately on unexpected calls

I've migrated to this trait since PHPUnit deprecated its integration with Prophecy.

I've struggled a little since then, but I've now found the root of my issue: mocks are not failing immediately as before.

This is a reproducer:

<?php

declare(strict_types=1);

class MockRegressionTest extends \PHPUnit\Framework\TestCase
{
    use ProphecyTrait;

    public function test(): void
    {
        $prophecy = $this->prophesize(\PHPUnit\Framework\TestSuite::class);
        $prophecy->addTestFile('foo.php')
            ->shouldBeCalledOnce();

        $prophecy->reveal()
            ->addTestFile('bar.php'); // should fail here

        $this->fail('If we got here, we have some trouble'); // goes on and fails here
    }
}

Test should fail immediately when calling the method with the wrong argument, but it doesn't. This leads to the mock returning null and either failing with a TypeError or going further, making the test failure a lot harder to debug.

Copying this reproducer into a PHPSpec test gets the right behavior.

Thanks to @DonCallisto for the help debugging this issue.