Highly opinionated mocking framework for PHP 5.3+

Last update: May 23, 2022


Stable release Build Status

Prophecy is a highly opinionated yet very powerful and flexible PHP object mocking framework. Though initially it was created to fulfil phpspec2 needs, it is flexible enough to be used inside any testing framework out there with minimal effort.

A simple example


class UserTest extends PHPUnit\Framework\TestCase
    private $prophet;

    public function testPasswordHashing()
        $hasher = $this->prophet->prophesize('App\Security\Hasher');
        $user   = new App\Entity\User($hasher->reveal());

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


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

    protected function setUp()
        $this->prophet = new \Prophecy\Prophet;

    protected function tearDown()



Prophecy requires PHP 7.2.0 or greater.

Setup through composer

First, add Prophecy to the list of dependencies inside your composer.json:

    "require-dev": {
        "phpspec/prophecy": "~1.0"

Then simply install it with composer:

$> composer install --prefer-dist

You can read more about Composer on its official webpage.

How to use it

First of all, in Prophecy every word has a logical meaning, even the name of the library itself (Prophecy). When you start feeling that, you'll become very fluid with this tool.

For example, Prophecy has been named that way because it concentrates on describing the future behavior of objects with very limited knowledge about them. But as with any other prophecy, those object prophecies can't create themselves - there should be a Prophet:

$prophet = new Prophecy\Prophet;

The Prophet creates prophecies by prophesizing them:

$prophecy = $prophet->prophesize();

The result of the prophesize() method call is a new object of class ObjectProphecy. Yes, that's your specific object prophecy, which describes how your object would behave in the near future. But first, you need to specify which object you're talking about, right?


There are 2 interesting calls - willExtend and willImplement. The first one tells object prophecy that our object should extend a specific class. The second one says that it should implement some interface. Obviously, objects in PHP can implement multiple interfaces, but extend only one parent class.


Ok, now we have our object prophecy. What can we do with it? First of all, we can get our object dummy by revealing its prophecy:

$dummy = $prophecy->reveal();

The $dummy variable now holds a special dummy object. Dummy objects are objects that extend and/or implement preset classes/interfaces by overriding all their public methods. The key point about dummies is that they do not hold any logic - they just do nothing. Any method of the dummy will always return null and the dummy will never throw any exceptions. Dummy is your friend if you don't care about the actual behavior of this double and just need a token object to satisfy a method typehint.

You need to understand one thing - a dummy is not a prophecy. Your object prophecy is still assigned to $prophecy variable and in order to manipulate with your expectations, you should work with it. $dummy is a dummy - a simple php object that tries to fulfil your prophecy.


Ok, now we know how to create basic prophecies and reveal dummies from them. That's awesome if we don't care about our doubles (objects that reflect originals) interactions. If we do, we need to use stubs or mocks.

A stub is an object double, which doesn't have any expectations about the object behavior, but when put in specific environment, behaves in specific way. Ok, I know, it's cryptic, but bear with me for a minute. Simply put, a stub is a dummy, which depending on the called method signature does different things (has logic). To create stubs in Prophecy:


Oh wow. We've just made an arbitrary call on the object prophecy? Yes, we did. And this call returned us a new object instance of class MethodProphecy. Yep, that's a specific method with arguments prophecy. Method prophecies give you the ability to create method promises or predictions. We'll talk about method predictions later in the Mocks section.


Promises are logical blocks, that represent your fictional methods in prophecy terms and they are handled by the MethodProphecy::will(PromiseInterface $promise) method. As a matter of fact, the call that we made earlier (willReturn('value')) is a simple shortcut to:

$prophecy->read('123')->will(new Prophecy\Promise\ReturnPromise(array('value')));

This promise will cause any call to our double's read() method with exactly one argument - '123' to always return 'value'. But that's only for this promise, there's plenty others you can use:

  • ReturnPromise or ->willReturn(1) - returns a value from a method call
  • ReturnArgumentPromise or ->willReturnArgument($index) - returns the nth method argument from call
  • ThrowPromise or ->willThrow($exception) - causes the method to throw specific exception
  • CallbackPromise or ->will($callback) - gives you a quick way to define your own custom logic

Keep in mind, that you can always add even more promises by implementing Prophecy\Promise\PromiseInterface.

Method prophecies idempotency

Prophecy enforces same method prophecies and, as a consequence, same promises and predictions for the same method calls with the same arguments. This means:

$methodProphecy1 = $prophecy->read('123');
$methodProphecy2 = $prophecy->read('123');
$methodProphecy3 = $prophecy->read('321');

$methodProphecy1 === $methodProphecy2;
$methodProphecy1 !== $methodProphecy3;

That's interesting, right? Now you might ask me how would you define more complex behaviors where some method call changes behavior of others. In PHPUnit or Mockery you do that by predicting how many times your method will be called. In Prophecy, you'll use promises for that:


// For PHP 5.4
$user->setName('everzet')->will(function () {

// For PHP 5.3
$user->setName('everzet')->will(function ($args, $user) {

// Or
$user->setName('everzet')->will(function ($args) use ($user) {

And now it doesn't matter how many times or in which order your methods are called. What matters is their behaviors and how well you faked it.

Note: If the method is called several times, you can use the following syntax to return different values for each call:

$prophecy->read('123')->willReturn(1, 2, 3);

This feature is actually not recommended for most cases. Relying on the order of calls for the same arguments tends to make test fragile, as adding one more call can break everything.

Arguments wildcarding

The previous example is awesome (at least I hope it is for you), but that's not optimal enough. We hardcoded 'everzet' in our expectation. Isn't there a better way? In fact there is, but it involves understanding what this 'everzet' actually is.

You see, even if method arguments used during method prophecy creation look like simple method arguments, in reality they are not. They are argument token wildcards. As a matter of fact, ->setName('everzet') looks like a simple call just because Prophecy automatically transforms it under the hood into:

$user->setName(new Prophecy\Argument\Token\ExactValueToken('everzet'));

Those argument tokens are simple PHP classes, that implement Prophecy\Argument\Token\TokenInterface and tell Prophecy how to compare real arguments with your expectations. And yes, those classnames are damn big. That's why there's a shortcut class Prophecy\Argument, which you can use to create tokens like that:

use Prophecy\Argument;


ExactValueToken is not very useful in our case as it forced us to hardcode the username. That's why Prophecy comes bundled with a bunch of other tokens:

  • IdenticalValueToken or Argument::is($value) - checks that the argument is identical to a specific value
  • ExactValueToken or Argument::exact($value) - checks that the argument matches a specific value
  • TypeToken or Argument::type($typeOrClass) - checks that the argument matches a specific type or classname
  • ObjectStateToken or Argument::which($method, $value) - checks that the argument method returns a specific value
  • CallbackToken or Argument::that(callback) - checks that the argument matches a custom callback
  • AnyValueToken or Argument::any() - matches any argument
  • AnyValuesToken or Argument::cetera() - matches any arguments to the rest of the signature
  • StringContainsToken or Argument::containingString($value) - checks that the argument contains a specific string value
  • InArrayToken or Argument::in($array) - checks if value is in array
  • NotInArrayToken or Argument::notIn($array) - checks if value is not in array

And you can add even more by implementing TokenInterface with your own custom classes.

So, let's refactor our initial {set,get}Name() logic with argument tokens:

use Prophecy\Argument;


// For PHP 5.4
$user->setName(Argument::type('string'))->will(function ($args) {

// For PHP 5.3
$user->setName(Argument::type('string'))->will(function ($args, $user) {

// Or
$user->setName(Argument::type('string'))->will(function ($args) use ($user) {

That's it. Now our {set,get}Name() prophecy will work with any string argument provided to it. We've just described how our stub object should behave, even though the original object could have no behavior whatsoever.

One last bit about arguments now. You might ask, what happens in case of:

use Prophecy\Argument;


// For PHP 5.4
$user->setName(Argument::type('string'))->will(function ($args) {

// For PHP 5.3
$user->setName(Argument::type('string'))->will(function ($args, $user) {

// Or
$user->setName(Argument::type('string'))->will(function ($args) use ($user) {

$user->setName(Argument::any())->will(function () {

Nothing. Your stub will continue behaving the way it did before. That's because of how arguments wildcarding works. Every argument token type has a different score level, which wildcard then uses to calculate the final arguments match score and use the method prophecy promise that has the highest score. In this case, Argument::type() in case of success scores 5 and Argument::any() scores 3. So the type token wins, as does the first setName() method prophecy and its promise. The simple rule of thumb - more precise token always wins.

Getting stub objects

Ok, now we know how to define our prophecy method promises, let's get our stub from it:

$stub = $prophecy->reveal();

As you might see, the only difference between how we get dummies and stubs is that with stubs we describe every object conversation instead of just agreeing with null returns (object being dummy). As a matter of fact, after you define your first promise (method call), Prophecy will force you to define all the communications - it throws the UnexpectedCallException for any call you didn't describe with object prophecy before calling it on a stub.


Now we know how to define doubles without behavior (dummies) and doubles with behavior, but no expectations (stubs). What's left is doubles for which we have some expectations. These are called mocks and in Prophecy they look almost exactly the same as stubs, except that they define predictions instead of promises on method prophecies:



The shouldBeCalled() method here assigns CallPrediction to our method prophecy. Predictions are a delayed behavior check for your prophecies. You see, during the entire lifetime of your doubles, Prophecy records every single call you're making against it inside your code. After that, Prophecy can use this collected information to check if it matches defined predictions. You can assign predictions to method prophecies using the MethodProphecy::should(PredictionInterface $prediction) method. As a matter of fact, the shouldBeCalled() method we used earlier is just a shortcut to:

$entityManager->flush()->should(new Prophecy\Prediction\CallPrediction());

It checks if your method of interest (that matches both the method name and the arguments wildcard) was called 1 or more times. If the prediction failed then it throws an exception. When does this check happen? Whenever you call checkPredictions() on the main Prophet object:


In PHPUnit, you would want to put this call into the tearDown() method. If no predictions are defined, it would do nothing. So it won't harm to call it after every test.

There are plenty more predictions you can play with:

  • CallPrediction or shouldBeCalled() - checks that the method has been called 1 or more times
  • NoCallsPrediction or shouldNotBeCalled() - checks that the method has not been called
  • CallTimesPrediction or shouldBeCalledTimes($count) - checks that the method has been called $count times
  • CallbackPrediction or should($callback) - checks the method against your own custom callback

Of course, you can always create your own custom prediction any time by implementing PredictionInterface.


The last bit of awesomeness in Prophecy is out-of-the-box spies support. As I said in the previous section, Prophecy records every call made during the double's entire lifetime. This means you don't need to record predictions in order to check them. You can also do it manually by using the MethodProphecy::shouldHave(PredictionInterface $prediction) method:

$em = $prophet->prophesize('Doctrine\ORM\EntityManager');



Such manipulation with doubles is called spying. And with Prophecy it just works.


  • 1. Partial Mocks


    I know that the purpose of this library is mainly for PHPSpec and therefore tries to satifsy another purpose. I still use it in regular tests, because the API is so easy to use, especially compared to PHPUnit mocks. Unfortunately there is one downside: Prophecy is not able to create partial mocks. Sometimes I want to test a method that gets Data from the same object but from another method. And I don't want to set up all data for the other method, because I want to unit test only one. In such a scenario, I would need to mock only one method, which I understand is currently not possible neither intended to be possible in prophecy.

    I just think that this tool is to useful to limit it just for PHPSpec. My question therefore is, if it would be possible to implement partial mocks in the future?

    Reviewed by KeKs0r at 2013-10-18 09:28
  • 2. Add PHP 7.1 support

    resolves: https://github.com/phpspec/prophecy/issues/280

    • Allows void return type
    • Allows iterable type
    • Allows nullable arguments
    • Allows nullable return types
    Reviewed by prolic at 2016-09-26 10:23
  • 3. Introduced and fixed CachedDoubler behaviour in order to reduce memor…

    …y usage

    With this PR we resolve https://github.com/phpspec/prophecy/issues/96 and https://github.com/phpspec/phpspec/issues/884.

    Our empirical tests:

    ~ 6000 PHPSpec examples

    Before patch:

    • 1GB 900MB memory consumption
    • 31676 declared classes
    • 105 seconds per suite execution

    After patch:

    • 146MB (-1.301 %)
    • 3148 declared classes (-1.006 %)
    • 9 seconds per suite execution (- 1.166 %)

    Only thing that should be considered here is the static-ness nature of CachedDoubler. Is this fine or is it improvable?

    Reviewed by DonCallisto at 2018-11-03 12:48
  • 4. Mock magic methods

    Hi there.

    Sorry to open this issue, seems that it was already discussed, here, here and here.

    But, right now there is no solution to mock object that didn't define public API using PHP implementations. And sadly, many libraries uses magic calls, just talk about the example : AWS. I Guess that I can find other popular examples.

    AWS use PHPDoc to describe API when doing magic functions, see PhpDoc @method.

    So, what about using this information to read public API ? PHPStorm use this information to build auto-completion.


    Reviewed by armetiz at 2014-01-13 12:27
  • 5. add support for 'self' and 'parent' return type

    When a php7 return type is self, like so:

    class Foo {
      public function setBar(Bar $bar) : self
          return $this;

    Extending Foo::setBar like so

    class Baz extends Foo {
      public function setBar(Bar $bar) : self

    will result in

    Compile Error: Declaration of Baz::setBar(Bar $bar): Baz must be compatible with Foo::setBar(Bar $bar): Foo

    So the extending class must respect the return type:

    class Baz extends Foo {
      public function setBar(Bar $bar) : Foo
    Reviewed by bendavies at 2016-02-08 11:30
  • 6. Partial Mocking

    Hi guys, There is any news about Partial Mocking supported in v1 ? Here is an example:

    function it_will_call_b_and_delegate_to_a() {
      $this->a('foo', 'bar')->shouldBeCalled();
    public function a($foo, $bar) {
      // do a
    public function b($bar) {
      // do something to create foo
      $this->a($foo, $bar);

    With partial mocks will be possible to mocking $this public methods.

    Reviewed by hlegius at 2014-04-02 16:55
  • 7. Problem while doubling MongoDB ODM QueryBuilder


    I'm having trouble mocking a Doctrine\ODM\MongoDB\Query\Builder object. In fact, this class uses an optionnal dependency "GeoJson" to perform geo-related operation.

    Problem appends when this package is not installed, prophecy will generate a non PHP standard compliant class (because one of the QB method is typehinted with a GeoJson class).

    You can see the problem happening here: https://travis-ci.org/akeneo/pim-community-dev/jobs/21412381#L510

    I'm not really convinced this is a prophecy issue, maybe it's more a mongodb-odm issue that should not bring hard-coupling between an optionnal dependency.

    Anyway, I've found an easy fix in https://github.com/phpspec/prophecy/blob/master/src/Prophecy/Doubler/Generator/ClassCodeGenerator.php#L77 which consits in always prepending \\ to the argument's class, but I'm not sure I totally get the purpose of this line 77.

    Could you enlight me, please?


    Reviewed by gquemener at 2014-03-24 10:04
  • 8. Implement Prophet::getNumberOfPredictions()

    For better integration with PHPUnit, for instance, it would be nice if a Prophet::getNumberOfPredictions() method existed that returns the number of predictions (expectations in PHPUnit terminilogy).

    In https://github.com/sebastianbergmann/phpunit/commit/6c21c66567031c863f207fb46b3c1c545d5589d1 I added the following workaround for now:

    foreach ($this->prophet->getProphecies() as $objectProphecy) {
        foreach ($objectProphecy->getMethodProphecies() as $methodProphecies) {
            foreach ($methodProphecies as $methodProphecy) {
                if ($methodProphecy->getPrediction() !== null) {

    The above seems to work but this functionality should be part of Prophecy. This was already discussed in https://github.com/phpspec/prophecy-phpunit/pull/6 and https://github.com/phpspec/prophecy-phpunit/issues/13.

    Reviewed by sebastianbergmann at 2014-11-05 11:32
  • 9. 1.10.0 regression

    With the release of 1.10.0 we noticed some of our tests breaking. After some digging this is because the behavior has slightly changed. Maybe it's best explained with an example:

    require __DIR__ . '/vendor/autoload.php';
    class A {
        public function someMethod() {
            return 42;
        public function otherMethod() {
    class Regression {
        public function test(A $a) {
            try {
            } catch (\Throwable $e) {
                return false;
            return true;
    $prophet = new Prophecy\Prophet();
    $prophecy = $prophet->prophesize(A::class);
    var_dump((new Regression())->test($prophecy->reveal()));

    With 1.9.0 this outputs: bool(false) With 1.10.0 this outputs: bool(true)

    This is because the prophecy no longer throws an error when dealing with methods which have not been prophesied. And while I admit this is a poor test, it means that some of our tests are breaking and need fixing with a feature release.

    Is this an intended side effect?

    Reviewed by yannickl88 at 2019-12-18 08:39
  • 10. Mocking magic methods

    I'm trying to mock magic methods, and it's impossible. Specically __get and __set. I've written some work arounds to the problem, but the tests are unwieldy.

    Is there any simple way that I can mock ArrayAccess or Magic Methods?

    Reviewed by CMCDragonkai at 2013-05-09 22:22
  • 11. Trait method not being found?

    I have a trait on a class which shouldBeCalled how ever this prophecy is fine but when the tested code runs it says it doesn't exist on the object.

    My trait

    trait AppliesEvents
      public function apply(AggregateChanged $event);

    My class (gets mocked)

    class Deal
      use AppliesEvents;

    My test code:

        public function it_will_apply_unlist_deal_event_on_deal($deals, UnlistDealCommand $command, Deal $deal)

    The code being tested:

         * @param UnlistDealCommand $command
        public function handle(UnlistDealCommand $command)
            $deal = $this->deals->findByKey($command->dealId());
            if (is_null($deal)) {
                throw new \RuntimeException('Unable to locate deal.');
            $deal->apply(new UnlistDeal);

    If I var_dump($deal) I can see $methodProphecies contaons apply but when I call it I get

    it will apply unlist deal event on deal
    method `Double\Deal\P4::apply()` not found.

    Any ideas?

    Reviewed by bweston92 at 2015-06-24 14:28
  • 12. Idea: Using spl_object_id instead of spl_object_hash for stringified errors? (stdClass#1234 instead of stdClass:0000000046ef9d1d000000002ac5521e)

    https://php.net/spl_object_id requires php 7.2+, and the latest releases of prophecy also require php 7.2+. (aside: it has polyfills such as symfony/polyfill-php72)

    I'd personally find the object ids easier to read/distinguish from each other than the spl_object_hash/SplObjectStorage


          identical(Double\stdClass\P9:0000000046ef9d1d000000002ac5521e Object (
              'objectProphecyClosure' => Closure:0000000046ef8661000000002ac5521e Object (
                  0 => Closure:0000000046ef8661000000002ac5521e Object


          identical(Double\stdClass\P9#4480 Object (
              'objectProphecyClosure' => Closure#4458 Object (
                  0 => Closure#4458 Object
    diff --git a/src/Prophecy/Util/ExportUtil.php b/src/Prophecy/Util/ExportUtil.php
    index 1090a80..218c02d 100644
    --- a/src/Prophecy/Util/ExportUtil.php
    +++ b/src/Prophecy/Util/ExportUtil.php
    @@ -91,7 +91,7 @@ class ExportUtil
                 foreach ($value as $key => $val) {
    -                $array[spl_object_hash($val)] = array(
    +                $array[spl_object_id($val)] = array(
                         'obj' => $val,
                         'inf' => $value->getInfo(),
    @@ -181,11 +181,11 @@ class ExportUtil
             if (is_object($value)) {
                 $class = get_class($value);
    -            if ($hash = $processed->contains($value)) {
    -                return sprintf('%s:%s Object', $class, $hash);
    +            if ($processed->contains($value)) {
    +                return sprintf('%s#%d Object', $class, spl_object_id($value));
    -            $hash   = $processed->add($value);
    +            $processed->add($value);
                 $values = '';
                 $array  = self::toArray($value);
    @@ -202,7 +202,7 @@ class ExportUtil
                     $values = "\n" . $values . $whitespace;
    -            return sprintf('%s:%s Object (%s)', $class, $hash, $values);
    +            return sprintf('%s#%d Object (%s)', $class, spl_object_id($value), $values);
             return var_export($value, true);
    diff --git a/src/Prophecy/Util/StringUtil.php b/src/Prophecy/Util/StringUtil.php
    index ba4faff..b63181e 100644
    --- a/src/Prophecy/Util/StringUtil.php
    +++ b/src/Prophecy/Util/StringUtil.php
    @@ -56,7 +56,7 @@ class StringUtil
                 return get_resource_type($value).':'.$value;
             if (is_object($value)) {
    -            return $exportObject ? ExportUtil::export($value) : sprintf('%s:%s', get_class($value), spl_object_hash($value));
    +            return $exportObject ? ExportUtil::export($value) : sprintf('%s#%s', get_class($value), spl_object_id($value));
             if (true === $value || false === $value) {
                 return $value ? 'true' : 'false';
    Reviewed by TysonAndre at 2021-12-12 16:04
  • 13. PHP8 named arguments are not supported

    I found out that it's not possible to mock methods which are using named parameters. Example:

    $this->repository = $this->prophesize(Repository::class);
                ->get([self::ID], orderBy: 'sort, id')

    The same parameters are used in the referenced method, but still, I can't mock this function and receive the error: Return value must be of type Objects, null returned.

    When I provide defaults values for all the preceding parameters it works fine.

    Reviewed by jorgsowa at 2021-11-26 10:40
  • 14. Feature Request: PHPDoc generics typehints

    It would be amazing if we could typehint our prophecies with Generics phpdoc:

     * @var ObjectProphecy<ClassBeingMocked>
    private $prophecy;
    Reviewed by tyteen4a03 at 2021-09-16 11:46
  • 15. Intersection types in generated code

    We need to ensure that if a class uses intersection return or argument type hints, that we generate the correct code when it's doubled.

    Based on the work for union types this could be complex :/


    Reviewed by ciaranmcnulty at 2021-08-10 08:54
Related tags
PHP Mocking Framework

Phake Phake is a framework for PHP that aims to provide mock objects, test doubles and method stubs. Phake was inspired by a lack of flexibility and e

May 16, 2022
The most powerful and flexible mocking framework for PHPUnit / Codeception.

AspectMock AspectMock is not an ordinary PHP mocking framework. With the power of Aspect Oriented programming and the awesome Go-AOP library, AspectMo

May 18, 2022
A PHP library for mocking date and time in tests

ClockMock Slope s.r.l. ClockMock provides a way for mocking the current timestamp used by PHP for \DateTime(Immutable) objects and date/time related f

Apr 11, 2022
Add mocking capabilities to Pest or PHPUnit

This repository contains the Pest Plugin Mock. The Mocking API can be used in regular PHPUnit projects. For that, you just have to run the following c

Feb 28, 2022
The modern, simple and intuitive PHP unit testing framework.

atoum PHP version atoum version 5.3 -> 5.6 1.x -> 3.x 7.2 -> 8.x 4.x (current) A simple, modern and intuitive unit testing framework for PHP! Just lik

May 18, 2022
Full-stack testing PHP framework

Codeception Modern PHP Testing for everyone Codeception is a modern full-stack testing framework for PHP. Inspired by BDD, it provides an absolutely n

May 19, 2022
AST based PHP Mutation Testing Framework

Infection - Mutation Testing framework Please read documentation here: infection.github.io Twitter: @infection_php Discord: https://discord.gg/ZUmyHTJ

May 16, 2022
:heavy_check_mark: PHP Test Framework for Freedom, Truth, and Justice
:heavy_check_mark: PHP Test Framework for Freedom, Truth, and Justice

Kahlan is a full-featured Unit & BDD test framework a la RSpec/JSpec which uses a describe-it syntax and moves testing in PHP one step forward. Kahlan

May 6, 2022
Event driven BDD test framework for PHP
Event driven BDD test framework for PHP

The highly extensible, highly enjoyable, PHP testing framework. Read more at peridot-php.github.io or head over to the wiki. Building PHAR Peridot's p

Apr 8, 2022
BDD test framework for PHP

BDD test framework for PHP, inspired by Jasmine and RSpec. Features a familiar syntax, and a watch command to automatically re-run specs during develo

Feb 11, 2022
SpecBDD Framework for PHP

phpspec The main website with documentation is at http://www.phpspec.net. Installing Dependencies Dependencies are handled via composer: wget -nc http

May 16, 2022
The PHP Unit Testing framework.

PHPUnit PHPUnit is a programmer-oriented testing framework for PHP. It is an instance of the xUnit architecture for unit testing frameworks. Installat

May 26, 2022
PHP unit testing framework with built in mocks and stubs. Runs in the browser, or via the command line.

Enhance PHP A unit testing framework with mocks and stubs. Built for PHP, in PHP! Quick Start: Just add EnhanceTestFramework.php and you are ready to

May 2, 2022
Pest is an elegant PHP Testing Framework with a focus on simplicity
Pest is an elegant PHP Testing Framework with a focus on simplicity

Pest is an elegant PHP Testing Framework with a focus on simplicity. It was carefully crafted to bring the joy of testing to PHP. Explore the docs: pe

May 19, 2022
SimpleTest is a framework for unit testing, web site testing and mock objects for PHP

SimpleTest SimpleTest is a framework for unit testing, web site testing and mock objects for PHP. Installation Downloads All downloads are stored on G

Apr 21, 2022
Humbug - a Mutation Testing framework for PHP

Humbug is a Mutation Testing framework for PHP to measure the real effectiveness of your test suites and assist in their improvement. It eats Code Coverage for breakfast.

May 19, 2022
vfsStream is a stream wrapper for a virtual file system that may be helpful in unit tests to mock the real file system. It can be used with any unit test framework, like PHPUnit or SimpleTest.

vfsStream vfsStream is a stream wrapper for a virtual file system that may be helpful in unit tests to mock the real file system. It can be used with

May 15, 2022
Wraps your Pest suite in a Laravel application instance, allowing global use of the framework in tests.

Pest Larastrap Plugin This is currently a highly experimental project and is subject to large pre-release changes. Pest PHP is an awesome PHP testing

Jan 6, 2022