PHPUnit has a test mode designed to "report useless tests" which marks tests that do not perform any assertions or expectations. However, PHPUnit is ignorant to any expectations performed on Mockery objects since Mockery has no integration with PHPUnit.

I've corrected a few typos and formatting derps, and I have moved all the documentation to a docs folder. Each h2 heading now has it's own file. I have updated the contents page on the readme for this change.

Had a play with this tonight, basic use:

<?php

$spy = m::spy();
$spy->myMethod();
$spy->shouldHaveReceived("myMethod");

It wont handle some weird cases, because it tries to verify on the fly, i.e., you don't have to manually call a verify method. Having such a requirement would make it possible to do

<?php

$spy->shouldNotHaveReceived("find")->with(123)->verify();

However, I'm not really sure I'd ever really write code that would require that, and even if I did, I could always fall back to mocks with expectations.

Would appreciate thoughts, I'm keen to get some kind of spy implementation in soon so people can give it a good look before we settle on an API for 1.0.

I think would be handy a method like

withArgs($closure)

that would work similar to

with( Mockery::on($closure) );

with the only difference that in first case the $closurereceives all the arguments passed to the target method.

I'm referring to this documentation of PHPUnit for creating mocked object that all methods are stubs, which return null by default: Unit Testing Tutorial (Do not call setMethods() & Passing an empty array)

This kind of feature doesn't seems currently available on Mockery.

One option that close to that is shouldIgnoreMissing(), but this option will always return null even when the method being called is not exists. This is not good when there's a typo in either unit test's class or actual class.

The additional option of makeStubs() works alike, but will still throw error when a nonexistent method is called.

When using mocky assertions with PHPUnit 6.3:

$eventListener = \Mockery::mock(EventListenerInterface::class)
            ->shouldNotReceive('handle')
            ->getMock();

I can update the assertion count by doing something like

protected function tearDown()
    {
        if ($container = \Mockery::getContainer()) {
            $this->addToAssertionCount($container->mockery_getExpectationCount());
        }

        parent::tearDown();
    }

Which is kind of annoying but ok. As long as it gets rid of the warning about no assertions.

This doesn't work however:

$eventListener = \Mockery::spy(EventListenerInterface::class);
$eventListener->shouldHaveNotReceived('handle')

Since apparently spy assertions don't update the exceptations and thus the expectation count.

Is there a better way to go about this, other than doing something likebeStrictAboutTestsThatDoNotTestAnything="false"?

After recent changes partial mocking of constructor doesn't work.

namespace Acme;

class ExampleClass
{
    public function __construct(DependencyInterface $dep)
    {
    }
}

\Mockery::mock('Acme\ExampleClass[__construct]');

After running phpunit following error occurs:

Argument 1 passed to 'Mockery_518b69580914a::__construct() must implement interface Acme\DependencyInterface, none given

From my observations the Mockery seems to store all created mock instances (or at least their expectations) somewhere internally. This can cause problems in large tests, when after mock is no longer needed in one of the tests it's not being garbage collected, because Mockery container has reference to it.

I think, that we can safely assume, that by the time, when Mockery test listener is called by PHPUnit (in tearDownAfterClass), then we can free memory by removing unused mocks.

If somebody wants to test, then feel free to grab https://github.com/aik099/qa-tools, which test suite is using Mockery extensivery and can eat up till 300MB of memory.

This was too much for TravisCI and I decided to run tests in parallel to make each process memory consumption smaller.

Hi,

I am having problem with partial mock and use of $this inside of it.

I will put some code sample to be clearer.

In my test I have something like below:

$serviceMock = Mockery::mock('Service');
$serviceMock->shouldReceive('spam')->andReturn('eggs');

$foobar = Mockery::mock(new Foobar($foo));
$foobar->shouldReceive('getService')
    ->andReturn($serviceMock);

$foobar->useService();

In my real code I have something like this:

class Foobar {
    public function __construct($foo) { 
        $this->foo = $foo;
    }

    public function useService() {
        $bacon = $this->foo->bacon();

        $service = $this->getService();
        $eggs = $service->spam();

        return $bacon + $eggs;
    }

    public function getService() {
        return new RealService(); // hits network and I don't want to hit it
    }
}

I was migrating a PHPUnit test to Mockery and I had this problem, I believe one way to do it is using Injection, something like setService($service), but right now I have a huge code base that works with PHPUnit. Is this a bug of Mockery or something expected to happen?

Thanks for your help!

Change parameter type integer to int to fix php 7 type definition.

Example: This code:

class php7

public function getId(int $id)
{
}

Generate:

class php7

public function getId(integer $id)
{
}

But is don't work because php don't recognize it code.

With replace genarete:

class php7

public function getId(int $id)
{
}

Together with @cordoval and @davedevelopment we've updated @cordoval version of Hamcrest-php library on GitHub (to 1.1.0) and published it on Composer as well.

Then fork of @davedevelopment (based on 1.0.0) would be deleted and your tests would break. To prevent that I've changed a dependency to correct Composer package.

I've also made tests use Hamcrest from Composer, rather one from PEAR. I've checked, that all tests pass (some were skipped) after the changes.

I have a problem that I don't know if it's a problem or it's normal.

I have a PHP class with static methods that I want to mock with Mockery to check that the code executed when an exception is thrown works.

The test works fine and does what I ask of it (The code tests the handling of an exception). ✔ Should throw exception [90.20 ms]

But when I want to pass the coverage with phpunit this happens:

Generating code coverage report in HTML format ...
Script phpunit --testdox --configuration ../phpunit.xml ../tests handling the test:coverage event returned with error code 255
Fatal error: Cannot declare class BackBase\Tools\Email\EmailManager, because the name is already in use in

I have seen in a thousand places that if I add

      * @runInSeparateProcess
      * @preserveGlobalState disable

in my test, everything is fixed.

But the times that each test takes increase a lot. ✔ Should throw exception [3331.97 ms]

I have many tests of this style and the test time increases exponentially.

Does this have a solution? I am doing something wrong? If more information is needed, ask me.

Thank you!

final class Foo
{
    public function foo() {
        return 123;
    }

    public function bar() {
        return $this->foo();
    }
}

// Tests
public function testFoo()
{
    $foo = new Foo();
    $mock = \Mockery::mock($foo);
    $mock->shouldReceive('foo')->andReturn(456);
    self::assertSame(456,$mock->bar());
}

I got an error message Failed asserting that 123 is identical to 456.

version

• php: 8.1
• phpunit: 9.5.26
• mockery: 1.5.1

The Mockery docs about overloading mention:

Using alias/instance mocks across more than one test will generate a fatal error since we can’t have two classes of the same name. To avoid this, run each test of this kind in a separate PHP process (which is supported out of the box by both PHPUnit and PHPT).

Instead of a fatal error, I see some odd behaviour that could either be a bug or something that should be documented:

I can overload the same class multiple times in the same PHP process. When I overload a class twice in the same test (which I did to find the limits of creating instance mocks), I found that only the expectations of the first overload are taken into account. Any assertions on a second overload of the same class are ignored without warning.

Here's the code that I used: https://github.com/jrfnl/bug-report-reproduction-scenarios/tree/mockery/overload-implementation-question

Am I interpreting the docs incorrectly? When should I expect a fatal error when creating instance mocks?

Calling the function on the mock results in an unexpected Undefined Constant error.

enum SimpleEnum {
    case single;
}
class EnumTest {
    public function call(SimpleEnum $enum = SimpleEnum::single) {
        echo $enum->name;
    }
}

$mock = Mockery::mock('EnumTest');
$mock->shouldReceive('call')->once();
$log = $mock->call();

   Error 

  Undefined constant "SimpleEnum"

  at vendor/mockery/mockery/library/Mockery/Loader/EvalLoader.php:34
     30▕         if (class_exists($definition->getClassName(), false)) {
     31▕             return;
     32▕         }
     33▕ 
  ➜  34▕         eval("?>" . $definition->getCode());
     35▕     }
     36▕ }
     37▕ 

  1   test.php:29
      Mockery_0_EnumTest::call()

Calling normally works as expected.

(new EnumTest())->call();

single

PHP 8.2 deprecated the use of dynamic properties. This impacts the use of Mockery when using anonymous mocks or mocks for classes which are not available.

The remaining 11 test failures for Mockery itself on PHP 8.2 are all related to this.

I'll be the first to admit I'm no Mockery expert, so I've been experimenting with how to work round the deprecation and so far I've not had much luck finding elegant solutions.

Now of course, one shouldn't mock what you do not own, but there are test situations where certain external dependencies (framework) may not be available during testing, so there's not much which can done about that.

Findings so far:

• Making the mock extend stdClass doesn't seem to work as this seems to run into trouble when the method under test has a class based parameter type declaration.
• Using Mockery::namedMock() and having the named mock extend stdClass, works for the first test case, but that's it. (also noted as such in the documentation). Re-using the mock object isn't really an option as the object won't be "clean" anymore if properties are being assigned from the tests.
• Along the same lines, using alias: mocks would require most tests to run in a separate process, which makes the test suite a lot slower as well as less stable.

Suggestions and "recipes" to solve this very welcome!