Consider this class
class Foo {
public function alias_method($input) {
return $this->actual_method($input);
}
public function actual_method($input) {
# Do something
}
}
Now, I have already written tests that verify the behavior of actual_method, so for alias_method, all I want to ensure is that it calls actual_method with $input.
How can I do this?
As you've asked for a code-example, this is a PHPUnit test method body that has your expectation set-up already:
/**
* TODO Find out whether or not the test is necessary
*
* Note: This example is a slight adoption from the Observer/Subject
* mock example from PHPUnit docs:
* Example 9.11: Testing that a method gets called once and with
* a specified argument
*
* #link http://phpunit.de/manual/current/en/test-doubles.html
*
* #test
*/
public function methodIsCalledWithInputArgument()
{
// Create an Input object to test with as method argument
$input = new Input();
// Create a mock for the Foo class,
// only mock the actual_method() method.
$foo = $this->getMock('Foo', array('actual_method'));
// Set up the expectation for the actual_method() method
// to be called only once and with the argument $input
// as its parameter.
$foo->expects($this->once())
->method('actual_method')
->with($this->identicalTo$(input))
;
// Call the alias_method() method on the $foo object
// which we expect to call the mocked Foo object's
// actual_method() method with $input.
$foo->alias_method($input);
}
Related
I am new to testing with PHPUnit, and what I am trying to do is test a method called returnOnLogin() that accepts a parameter Enlight_Event_EventArgs $args and returns true.
Here's the method I want to test:
public function returnOnLogin(\Enlight_Event_EventArgs $args)
{
$controller = $args->get('subject');
$view = $controller->View();
$controller->redirect([
'controller' => 'verification'
]);
// $view->addTemplateDir(
// __DIR__ . '/Views'
// );
return true;
}
Here's my test:
class MyFirstTestPluginTest extends TestCase
{
public function testReturnOnLogin()
{
$my_plugin = new MyFirstTestPlugin(true);
$expected = true;
//I tried following but it did not work
$this->assertEquals($expected, $my_plugin->returnOnLogin(//here is the problem it requires this array that I dont know));
}
}
Assuming that your controller class is Controller, and assuming that we don't care that view() is invoked in $controller, this should cover what you are looking for:
class MyFirstTestPluginTest extends TestCase
{
public function testReturnOnLogin()
{
/**
* create a test double for the controller (adjust to your controller class)
*/
$controller = $this->createMock(Controller::class);
/**
* expect that a method redirect() is called with specific arguments
*/
$controller
->expects($this->once())
->method('redirect')
->with($this->identicalTo([
'controller' => 'verification'
]));
/**
* create a test double for the arguments passed to returnLogin()
*/
$args = $this->createMock(\Enlight_Event_EventArgs::class);
/**
* expect that a method subject() is invoked and return the controller from it
*/
$args
->expects($this->once())
->method('subject')
->willReturn($controller);
$plugin = new MyFirstTestPlugin(true);
$this->assertTrue($plugin->returnOnLogin($args));
}
}
What does this test do?
Arrange
This test first arranges test doubles for use with the system under test (your plugin).
The first test double is your controller, we set it up in such a way that we expect that a method redirect() is invoked once with an argument that is identical to the specified array.
The second test double is the argument, we set it up in such a way that we expect that a method 'subject()` is invoked one, and will return the controller.
Then, we set up the system under test, simply by creating an instance of MyFirstTestPlugin, passing true to the constructor.
Unfortunately, you haven't shared the constructor with us, we have no idea what the argument true stands for. If it affects the behaviour of returnLogin(), then we clearly need to add more tests to assert the behaviour when the argument takes different values.
Act
Then this test invokes the method returnLogin() on the system under test, and passes in one of the test doubles.
Assert
Eventually, this test asserts that the method returnLogin() returns true.
Note Take a look at
http://wiki.c2.com/?ArrangeActAssert
https://phpunit.de/manual/current/en/test-doubles.html
I have a pretty basic function in my class that does exactly as the comment say, it just forwards calls to the child model if they don't exist on this class.
This works perfectly from my tests.
/**
* Handles calling methods on the user model directly from the provider
* Allows e.g. Guardian::User()->findOrFail(1) without having to redeclare
* the methods.
*
* #param $method
* #param $parameters
*
* #return mixed
*/
public function __call($method, $parameters){
$user = $this->createModel();
return call_user_func_array([$user, $method], $parameters);
}
However I also want to write unit tests for this, in which case the test I tried writing:
public function testProviderAsksModelToFind(){
$factoryUser = Factory::attributesFor('User', ['id' => 1]);
$p = m::mock('Webfox\Guardian\User\Guardian\Provider[createModel]',['']);
$user = m::mock('Webfox\Guardian\User\Guardian\User[find]');
$p->shouldReceive('createModel')->once()->andReturn($user);
$user->shouldReceive('find')->with(1)->once()->andReturn($factoryUser);
$this->assertSame($factoryUser, $p->find(1));
}
However this is spitting out the lovely error below:
1) EloquentUserProviderTest::testProviderAsksModelToFind
BadMethodCallException: Method
Webfox\Guardian\User\Guardian\Provider::find() does not exist on this
mock object
So, how do I fix this so my test passes?
The funny part is that method find is called on Provider Mock class. The error claims that. Shouldn't it be:
$this->assertSame($factoryUser, $user->find(1));
?
Code will explain everything:
<?php
class ATest extends PHPUnit_Framework_TestCase
{
public function testDestructorOnOriginalClass() {
$a = new A(); // It
unset($a); // works
echo " great!"; // great!
$this->expectOutputString('It works great!');
}
public function testDestructorOnMockedClass() {
$a = $this->getMock('A', array('someNonExistingMethod')); // It
unset($a); // works
echo " great!"; // great!
$this->expectOutputString('It works great!');
}
}
class A {
public function __construct()
{
echo "It";
}
public function __destruct()
{
echo " works";
}
}
and the output:
# phpunit ATest.php
PHPUnit 3.7.13 by Sebastian Bergmann.
.F
Time: 0 seconds, Memory: 3.50Mb
There was 1 failure:
1) ATest::testDestructorOnMockedClass
Failed asserting that two strings are equal.
--- Expected
+++ Actual
## ##
-'It works great!'
+'It great! works'
FAILURES!
Tests: 2, Assertions: 2, Failures: 1.
As you can see in the second test it prints works in wrong order, probably because phpunit stores reference to mock somewhere and __destruct() is called at the end of test... Ok I've already checked getMock() method and indeed it stores reference to mocked object ($this->mockObjects[] = $mockObject;) efficiently blocking object from being destructed and so __destructor() is never called.
/**
* Returns a mock object for the specified class.
*
* #param string $originalClassName
* #param array $methods
* #param array $arguments
* #param string $mockClassName
* #param boolean $callOriginalConstructor
* #param boolean $callOriginalClone
* #param boolean $callAutoload
* #param boolean $cloneArguments
* #return PHPUnit_Framework_MockObject_MockObject
* #throws PHPUnit_Framework_Exception
* #since Method available since Release 3.0.0
*/
public function getMock($originalClassName, $methods = array(), array $arguments = array(), $mockClassName = '', $callOriginalConstructor = TRUE, $callOriginalClone = TRUE, $callAutoload = TRUE, $cloneArguments = FALSE)
{
$mockObject = PHPUnit_Framework_MockObject_Generator::getMock(
$originalClassName,
$methods,
$arguments,
$mockClassName,
$callOriginalConstructor,
$callOriginalClone,
$callAutoload,
$cloneArguments
);
$this->mockObjects[] = $mockObject;
return $mockObject;
}
So the question is - is there a way to prevent this? Ignoring __destruct() when it should be called is I think bad limitation.
The thing is when you don't pass any values to a second parameter of "getMock" method, PHPUnit will stub all methods from the class you are mocking (including "__destruct").
But if you specify at least one method (it may be even non existing method) PHPUnit will stub only these methods you pass in second argument.
So if you want keep all methods, but you want also create mock, you should do this in that way:
$mock = $this->getMock('A', array('someNonExistingMethod'));
If you change this line you test should pass.
You're just unsetting the local variable - you are not destroying the object itself.
The object is also kept by PHPUnit itself, too. So there is still a reference around, thus your unset() does not lead to a __destruct().
So, the current behavior cannot be changed. Open a bug in the phpunit issue tracker.
If we clone the mock object and unset it, __destruct() of the cloned object can be called during the test. It may help you to test __destruct().
Please note that this method cannot prevent __destruct() of the original mock object to be called at the end of the test.
I have one test method that depends on another method that itself uses a data provider in PHPUnit:
/**
* #dataProvider getFields
*/
public function testCanDoSomeStuff($parm1, $parm2) {
$result = my_func($parm1, $parm2);
$this->assertNotNull($result);
return $result;
}
/**
* #depends testCanDoSomeStuff
*/
public function testCanDoSomeMoreStuff($result) {
$this->assertNotNull($result);
}
I also have a getFields() data provider function, no need to show that here.
The first test that relies on the data provider passes - $result is NOT null.
I expect that the result of the test will be passed to the dependent test as the $result parameter. However, the testCanDoSomeMoreStuff function receives a NULL parameter and the test fails.
Update
This simple test case demonstrates the problem:
class MyTest extends PHPUnit_Framework_TestCase {
/**
* #dataProvider myFunc
*/
public function testCanDoSomeStuff($value) {
$this->assertNotNull($value);
return $value;
}
/**
* #depends testCanDoSomeStuff
*/
public function testCanDoSomeMoreStuff($value) {
$this->assertNotNull($value);
}
/**
* Data provider function
*/
public function myFunc() {
$values = array('22');
return array($values);
}
}
As a workaround for now, I've stored the result in a static property between tests.
The problem is the result of several factors:
Each test result is stored in an array using the test's name as the key.
The name for a test that receives data is <name> with data set #<x>.
The #depends annotation doesn't accept multiple words.
There is a hacky workaround: override TestCase::getDataSetAsString to return a name that the annotation will accept. This is made slightly problematic since the required TestCase fields are private, but with PHP 5.3.2+ you can get around that.
Important: Unfortunately, you cannot have the dependent test run for every data row--only one specific row. If your data provider returns only one row of data, this isn't an issue.
Here's the code with a sample test. Note that you don't have to name your data row. If you leave off the 'foo' key, change the #depends to testOne-0.
class DependencyTest extends PHPUnit_Framework_TestCase
{
/**
* #dataProvider data
*/
public function testOne($x, $y) {
return $x + $y;
}
public function data() {
return array(
'foo' => array(1, 2),
);
}
/**
* #depends testOne-foo
*/
public function testTwo($z) {
self::assertEquals(3, $z);
}
protected function getDataSetAsString($includeData = false) {
if (!$includeData && $this->getPrivateField('data')) {
return '-' . $this->getPrivateField('dataName');
}
return parent::getDataSetAsString($includeData);
}
private function getPrivateField($name) {
$reflector = new ReflectionProperty('PHPUnit_Framework_TestCase', $name);
$reflector->setAccessible(true);
return $reflector->getValue($this);
}
}
Obviously, this is not a long-term solution. It would be better of you could have the dependent test run once for each test result from the method receiving the data. You could submit a feature request or pull request to PHPUnit.
If your $result in testCanDoSomeStuff() is really not null, then this should work.
To take this apart, first try to simplify it without the data provider, something like this:
class StackTest extends PHPUnit_Framework_TestCase {
public function testCanDoSomeStuff() {
$result = true;
$this->assertTrue($result);
return $result;
}
/**
* #depends testCanDoSomeStuff
*/
public function testCanDoSomeMoreStuff($result) {
$this->assertNotNull($result);
}
}
Testing this should result into something like...
~>phpunit test.php
PHPUnit 3.6.11 by Sebastian Bergmann.
..
Time: 1 second, Memory: 3.25Mb
OK (2 tests, 2 assertions)
Now add the data provider, replace my simple variable with your function and then test it again.
If this result differs, var_dump the variable $result before you return it in testcase testCanDoSomeStuff(). If it isn't null there, bug the behaviour.
I also expected the problem described to work, and after some research, I found out that this is not a bug, but an expected, not documented, behavior. The dependent test does not know about the data sets returned by the provider, and that's why the test parameter is null.
Source: https://github.com/sebastianbergmann/phpunit/issues/183#issuecomment-816066
The #dataProvider annotations get computed before test execution. Basically, the pre-test phase creates a test method for every set of parameters provided by the data provider. The #depends is dependent upon what is essentially the prototype of the data driven test, so in a way the #depends is on a non-existent (not executed test).
Another way to think of it, is that if provider was supplying more than one set of parameters. PHPUnit would make that many testDataProvider methods but there would not be that many testDataReceiver methods because there is not an #dataProvider method on that test method for the pre-test phase.
You can however had #depends and #dataProvider on the same test method. Just be careful to get the parameter order right, although in this case there may not be a first parameter.
Basically, you should use data providers when the data set has multiple rows. However, you can always use #depend and #dataProvider at the same time to achieve roughly the same behavior.
Is there any way to define different mock-expects for different input arguments? For example, I have database layer class called DB. This class has method called "Query ( string $query )", that method takes an SQL query string on input. Can I create mock for this class (DB) and set different return values for different Query method calls that depends on input query string?
It's not ideal to use at() if you can avoid it because as their docs claim
The $index parameter for the at() matcher refers to the index, starting at zero, in all method invocations for a given mock object. Exercise caution when using this matcher as it can lead to brittle tests which are too closely tied to specific implementation details.
Since 4.1 you can use withConsecutive eg.
$mock->expects($this->exactly(2))
->method('set')
->withConsecutive(
[$this->equalTo('foo'), $this->greaterThan(0)],
[$this->equalTo('bar'), $this->greaterThan(0)]
);
If you want to make it return on consecutive calls:
$mock->method('set')
->withConsecutive([$argA1, $argA2], [$argB1], [$argC1, $argC2])
->willReturnOnConsecutiveCalls($retValueA, $retValueB, $retValueC);
The PHPUnit Mocking library (by default) determines whether an expectation matches based solely on the matcher passed to expects parameter and the constraint passed to method. Because of this, two expect calls that only differ in the arguments passed to with will fail because both will match but only one will verify as having the expected behavior. See the reproduction case after the actual working example.
For you problem you need to use ->at() or ->will($this->returnCallback( as outlined in another question on the subject.
Example:
<?php
class DB {
public function Query($sSql) {
return "";
}
}
class fooTest extends PHPUnit_Framework_TestCase {
public function testMock() {
$mock = $this->getMock('DB', array('Query'));
$mock
->expects($this->exactly(2))
->method('Query')
->with($this->logicalOr(
$this->equalTo('select * from roles'),
$this->equalTo('select * from users')
))
->will($this->returnCallback(array($this, 'myCallback')));
var_dump($mock->Query("select * from users"));
var_dump($mock->Query("select * from roles"));
}
public function myCallback($foo) {
return "Called back: $foo";
}
}
Reproduces:
phpunit foo.php
PHPUnit 3.5.13 by Sebastian Bergmann.
string(32) "Called back: select * from users"
string(32) "Called back: select * from roles"
.
Time: 0 seconds, Memory: 4.25Mb
OK (1 test, 1 assertion)
Reproduce why two ->with() calls don't work:
<?php
class DB {
public function Query($sSql) {
return "";
}
}
class fooTest extends PHPUnit_Framework_TestCase {
public function testMock() {
$mock = $this->getMock('DB', array('Query'));
$mock
->expects($this->once())
->method('Query')
->with($this->equalTo('select * from users'))
->will($this->returnValue(array('fred', 'wilma', 'barney')));
$mock
->expects($this->once())
->method('Query')
->with($this->equalTo('select * from roles'))
->will($this->returnValue(array('admin', 'user')));
var_dump($mock->Query("select * from users"));
var_dump($mock->Query("select * from roles"));
}
}
Results in
phpunit foo.php
PHPUnit 3.5.13 by Sebastian Bergmann.
F
Time: 0 seconds, Memory: 4.25Mb
There was 1 failure:
1) fooTest::testMock
Failed asserting that two strings are equal.
--- Expected
+++ Actual
## ##
-select * from roles
+select * from users
/home/.../foo.php:27
FAILURES!
Tests: 1, Assertions: 0, Failures: 1
From what I've found, the best way to solve this problem is by using PHPUnit's value-map functionality.
Example from PHPUnit's documentation:
class SomeClass {
public function doSomething() {}
}
class StubTest extends \PHPUnit_Framework_TestCase {
public function testReturnValueMapStub() {
$mock = $this->getMock('SomeClass');
// Create a map of arguments to return values.
$map = array(
array('a', 'b', 'd'),
array('e', 'f', 'h')
);
// Configure the mock.
$mock->expects($this->any())
->method('doSomething')
->will($this->returnValueMap($map));
// $mock->doSomething() returns different values depending on
// the provided arguments.
$this->assertEquals('d', $stub->doSomething('a', 'b'));
$this->assertEquals('h', $stub->doSomething('e', 'f'));
}
}
This test passes. As you can see:
when the function is called with parameters "a" and "b", "d" is returned
when the function is called with parameters "e" and "f", "h" is returned
From what I can tell, this feature was introduced in PHPUnit 3.6, so it's "old" enough that it can be safely used on pretty much any development or staging environments and with any continuous integration tool.
It seems Mockery (https://github.com/padraic/mockery) supports this. In my case I want to check that 2 indices are created on a database:
Mockery, works:
use Mockery as m;
//...
$coll = m::mock(MongoCollection::class);
$db = m::mock(MongoDB::class);
$db->shouldReceive('selectCollection')->withAnyArgs()->times(1)->andReturn($coll);
$coll->shouldReceive('createIndex')->times(1)->with(['foo' => true]);
$coll->shouldReceive('createIndex')->times(1)->with(['bar' => true], ['unique' => true]);
new MyCollection($db);
PHPUnit, this fails:
$coll = $this->getMockBuilder(MongoCollection::class)->disableOriginalConstructor()->getMock();
$db = $this->getMockBuilder(MongoDB::class)->disableOriginalConstructor()->getMock();
$db->expects($this->once())->method('selectCollection')->with($this->anything())->willReturn($coll);
$coll->expects($this->atLeastOnce())->method('createIndex')->with(['foo' => true]);
$coll->expects($this->atLeastOnce())->method('createIndex')->with(['bar' => true], ['unique' => true]);
new MyCollection($db);
Mockery also has a nicer syntax IMHO. It appears to be a tad slower than PHPUnits built-in mocking capability, but YMMV.
Intro
Okay I see there is one solution provided for Mockery, so as I don't like Mockery, I am going to give you a Prophecy alternative but I would suggest you first to read about the difference between Mockery and Prophecy first.
Long story short: "Prophecy uses approach called message binding - it means that behaviour of the method does not change over time, but rather is changed by the other method."
Real world problematic code to cover
class Processor
{
/**
* #var MutatorResolver
*/
private $mutatorResolver;
/**
* #var ChunksStorage
*/
private $chunksStorage;
/**
* #param MutatorResolver $mutatorResolver
* #param ChunksStorage $chunksStorage
*/
public function __construct(MutatorResolver $mutatorResolver, ChunksStorage $chunksStorage)
{
$this->mutatorResolver = $mutatorResolver;
$this->chunksStorage = $chunksStorage;
}
/**
* #param Chunk $chunk
*
* #return bool
*/
public function process(Chunk $chunk): bool
{
$mutator = $this->mutatorResolver->resolve($chunk);
try {
$chunk->processingInProgress();
$this->chunksStorage->updateChunk($chunk);
$mutator->mutate($chunk);
$chunk->processingAccepted();
$this->chunksStorage->updateChunk($chunk);
}
catch (UnableToMutateChunkException $exception) {
$chunk->processingRejected();
$this->chunksStorage->updateChunk($chunk);
// Log the exception, maybe together with Chunk insert them into PostProcessing Queue
}
return false;
}
}
PhpUnit Prophecy solution
class ProcessorTest extends ChunkTestCase
{
/**
* #var Processor
*/
private $processor;
/**
* #var MutatorResolver|ObjectProphecy
*/
private $mutatorResolverProphecy;
/**
* #var ChunksStorage|ObjectProphecy
*/
private $chunkStorage;
public function setUp()
{
$this->mutatorResolverProphecy = $this->prophesize(MutatorResolver::class);
$this->chunkStorage = $this->prophesize(ChunksStorage::class);
$this->processor = new Processor(
$this->mutatorResolverProphecy->reveal(),
$this->chunkStorage->reveal()
);
}
public function testProcessShouldPersistChunkInCorrectStatusBeforeAndAfterTheMutateOperation()
{
$self = $this;
// Chunk is always passed with ACK_BY_QUEUE status to process()
$chunk = $this->createChunk();
$chunk->ackByQueue();
$campaignMutatorMock = $self->prophesize(CampaignMutator::class);
$campaignMutatorMock
->mutate($chunk)
->shouldBeCalled();
$this->mutatorResolverProphecy
->resolve($chunk)
->shouldBeCalled()
->willReturn($campaignMutatorMock->reveal());
$this->chunkStorage
->updateChunk($chunk)
->shouldBeCalled()
->will(
function($args) use ($self) {
$chunk = $args[0];
$self->assertTrue($chunk->status() === Chunk::STATUS_PROCESSING_IN_PROGRESS);
$self->chunkStorage
->updateChunk($chunk)
->shouldBeCalled()
->will(
function($args) use ($self) {
$chunk = $args[0];
$self->assertTrue($chunk->status() === Chunk::STATUS_PROCESSING_UPLOAD_ACCEPTED);
return true;
}
);
return true;
}
);
$this->processor->process($chunk);
}
}
Summary
Once again, Prophecy is more awesome! My trick is to leverage the messaging binding nature of Prophecy and even though it sadly looks like a typical, callback javascript hell code, starting with $self = $this; as you very rarely have to write unit tests like this I think it's a nice solution and it's definitely easy to follow, debug, as it actually describes the program execution.
BTW: There is a second alternative but requires changing the code we are testing. We could wrap the troublemakers and move them to a separate class:
$chunk->processingInProgress();
$this->chunksStorage->updateChunk($chunk);
could be wrapped as:
$processorChunkStorage->persistChunkToInProgress($chunk);
and that's it but as I didn't want to create another class for it, I prefer the first one.