I'm using PHPUnit 3.4.9, but I'm having some problems with the #depends annotation. It works like in the examples, but breaks when the producer reliers on a provider. I don't know if this is meant to work or not, but my code is basically in the form:
<?php
class StackTest extends PHPUnit_Framework_TestCase
{
/**
* #dataProvider provider
*/
public function testEmpty ($data)
{
$stack = array();
$this->assertTrue(empty($stack));
return $stack;
}
/**
* #depends testEmpty
*/
public function testPush (array $stack)
{
array_push($stack, 'foo');
$this->assertEquals('foo', $stack[count($stack)-1]);
$this->assertFalse(empty($stack));
return $stack;
}
/**
* #depends testPush
*/
public function testPop (array $stack)
{
$this->assertEquals('foo', array_pop($stack));
$this->assertTrue(empty($stack));
}
public function provider ()
{
return array(
// Some testing data here...
);
}
}
The code above is just an example, but shows what my code's structure is like. When ran, it skips the consumer tests, acting as though the producer had failed. I'm expecting that for every set of testing data in the provider, the producer will be run with that data, and all of its consumer correspondingly run.
Since the question is already 2 days old i give it a shot:
It doesn't seem to work the way you want it to.
#depends just looks if a test with the name provided has run and gets the result. It doesn't even know or care about the #annotations of said test.
I'd guess (haven't dug deep enough into the phpunit source to be 100% sure) tests with #depends are run as "group of tests" internally and not as a single one so there is not test named "testEmpty" and the depends fails.
So to provide a workaround the only thing i can think of right now is to call those "sub tests" directly.
<?php
class StackTest extends PHPUnit_Framework_TestCase {
/**
* #dataProvider provider
*/
public function testEmpty($data) {
$stack = array();
$this->assertTrue(empty($stack));
$this->nextTestOrJustAllInOneTestcaseSaidly($stack);
return $stack;
}
protected function nextTestOrJustAllInOneTestcaseSaidly($data) { ... }
Hope that helps or at least motivates someone else to answer ;)
I had the exact same problem with a test that depends on another test (and more specifically data returned by that test) which uses a data provider.
I overcame the problem by setting the value (which I would of normally simply returned from the dependent test) as a static variable, which I was then able to access in my other tests later.
<?php
class StackTest extends PHPUnit_Framework_TestCase {
protected static $foo;
public function provider() { ... }
/**
* #dataProvider provider
*/
public function testOne( $data ) {
self::$foo = array();
$this->assertTrue( empty( self::$foo ) );
}
/**
* #depends testOne
*/
public function testTwo() {
$this->assertTrue( empty( self::$foo ) );
}
Still hacky, but slightly less than perhaps calling the next test function from within another test.
If a test has a data provider, then all data provided will be fed into this test. Only then the next test is run, which might depend on the first test to succeed. What is NOT done is that all data provided to the first test is also fed to the second.
#dataProvider takes priority over #depends. A test can depend on another test that completely testes all of its data provided, but it won't get this data for itself. To get such a thing you really have to combine all dependant tests into one function.
On the other hand, such a test setup might be non-obvious in the first place, but tests should be easy to understand. Consider refactoring the tests.
Related
What is the correct way of setting a type for mocked objects?
Example code:
/**
* #dataProvider getTestDataProvider
* #throws Exception
*/
public function testExampleData(
Request $request,
Response $expected,
SomeClass $someClassMock
): void {
$result = $someClassMock->getData($request);
$this->assertEquals($expected, $result);
}
In this example the type of $someClassMock is class SomeClass. Also there is a type called MockObject which is also working properly, but it messes up the autocompletion of functions inside that class.
Which types should I use on these mocked objects? Real object class or MockObject?
What I do to make sure the auto completion works for the mocked class as well as the MockObject, is tell php that it can be either class. This adds the auto complete for both and also makes it quite understandable for anyone reading the code that it is a mock and what object it is mocking.
In your case it would look like this:
/**
* #dataProvider getTestDataProvider
* #throws Exception
*/
public function testExampleData(
Request $request,
Response $expected,
SomeClass|MockObject $someClassMock // <-- Change made here
): void {
$result = $someClassMock->getData($request);
$this->assertEquals($expected, $result);
}
You will still be passing in the MockObject, but your IDE will not complain about any unknown functions.
EDIT: To make it work with PHP versions before 8, I would suggest something like this (minimal example):
class ExampleTest extends TestCase
{
private someClass | MockObject $someClassMock;
public function setUp(): void
{
$this->someClassMock = $this->createMock(SomeClass::Class);
}
public function testMe()
{
$this->someClassMock->expects($this->once())->method('getData')->willReturn('someStuff');
}
}
In this scenario the variable $someClassMock is declared as both types and you can use it throughout your test with autocompletion for both of them. This should also work with your data provider although you might have to rewrite it slightly. I didn't include it in my example to keep it simple.
I have a class (called FormFilters), that class calls its methods within one method, in this case getProject.
class FormFilters extends KernelTestCase
{
public function getProject($filters)
{
$this->filters = $filters;
$this->getWhere($this->filters);
}
public function getWhere()
{
if ($this->filters->isValid()) {
$this->sql = $this->filterName($this->filters->get('name')->getData());
}
}
public function filterName()
{
//....
}
}
This is getProject method test:
public function test_getProject()
{
$formInterface = $this->createMock('Symfony\Component\Form\FormInterface');
$formInterface
->expects($this->at(0))
->method('isValid')
->willReturn(true); // come into conditional
$formInterface
->expects($this->at(1))
->method('get')
->with('name')
->will($this->returnSelf());
$formInterface
->expects($this->at(2))
->method('getData')
->will('data example');
$formFilters = new FormFilters();
$formFilters->getProject($formInterface); // my mock
}
So far all right. Now, I want to test getWhere method, I could do it independently, but if getProject has the same test (called to getWhere method), could I use the annotations #dataProvider or #depends, like this (example) :
/**
* #depends or/and #dataProvider test_getProject
*/
public function test_getWhere($dataToDepends)
{
// ... test ready !
}
It's possible ?
In your current set-up, positive case for getWhere() is already tested (in scope of test_getProject()). So, what is left to test in getWhere() is a negative case, when interpreter does not go inside of IF.
Test could be:
public function test_getWhere_invalid_filters()
{
$formInterface->expects($this->once())
->method('isValid')
->willReturn(false);
$formInterface->expects($this->never())
->method('get');
$formInterface->expects($this->never())
->method('getData');
$formFilters = new FormFilters();
//todo: inject $formInterface into $formFilterssomehow at this line.
$formFilters->getWhere();
}
Regarding your question with #depends - it's usually used when second test can not be executed before first is done. For example, first case creates some entity in database, and second test tries to delete entity, created in previous test. Another example - a static property of class, set in one test and expected to be read in another test. Generally speaking, having dependent tests, as well as dependent code units is not encouraged. And anyway, it's not your case, not what you need for the test.
Regarding #dataProvider - it's pretty usefull annotation. It allows to separate logic of the test from tested data. And also it allows to re-use same test with different data sets. Test, posted above, with #dataProvider will look like:
/**
* #dataProvider getWhere_invalid_filters_data_provider
*/
public function test_getWhere_invalid_filters($isValid, $getCallsCount, $getDataCallsCount)
{
$formInterface->expects($this->once())
->method('isValid')
->willReturn($isValid);
$formInterface->expects($this->exactly($getCallsCount))
->method('get');
$formInterface->expects($this->exactly($getDataCallsCount))
->method('getData');
$formFilters = new FormFilters();
//todo: inject $formInterface into $formFilterssomehow at this line.
$formFilters->getWhere();
}
public function getWhere_invalid_filters_data_provider()
{
return [
'case 1' => [
'isValid' => false,
'getCallsCount' => 0,
'getDataCallsCount' => 0,
],
];
}
Lately I'm giving a try to phpspec. It works great, but I have got a problem with testing command handlers. For example in PHPUnit I test it that way:
/**
* #test
*/
public function it_should_change_an_email()
{
$this->repository->add($this->employee);
$this->handler->changeEmail(
new ChangeEmailCommand(
$this->employee->username()->username(),
'new#email.com'
)
);
Asserts::assertEquals(new Email('new#email.com'), $this->employee->email());
}
and setup:
protected function setUp()
{
$this->repository = new InMemoryEmployeeRepository();
$this->createEmployee();
$this->handler = new EmployeeCommandHandler($this->repository);
}
The main point is that this test make assertions on the Employee object to check if CommandHandler is working good. But in phpspec I can't make assertion on different object than the specifying one, in this case I can only make assertion on my CommandHandler. So how I can test a command handler in phpspec?
EDIT
Maybe spies are the way to go:
class EmployeeCommandHandlerSpec extends ObjectBehavior
{
const USERNAME = 'johnny';
/** #var EmployeeRepository */
private $employeeRepository;
public function let(EmployeeRepository $employeeRepository)
{
$this->employeeRepository = $employeeRepository;
$this->beConstructedWith($employeeRepository);
}
public function it_changes_the_employee_email(Employee $employee)
{
$this->givenEmployeeExists($employee);
$this->changeEmail(
new ChangeEmailCommand(self::USERNAME, 'new#email.com')
);
$employee->changeEmail(new Email('new#email.com'))->shouldHaveBeenCalled();
}
private function givenEmployeeExists(Employee $employee)
{
$this->employeeRepository->employeeWithUsername(new EmployeeUsername(self::USERNAME))
->shouldBeCalled()
->willReturn($employee);
}
}
Employee class I've already speced. So, maybe, in command handler it'll be enough to just check if the method of the Employee has been called. What do you think about it? Am I going in good direction?
Messaging
Indeed, you shouldn't verify the state, but expect certain interactions between objects. That's what OOP is about afterall - messaging.
The way you've done it in PHPUnit is state verification. It forces you to expose the state as you need to provide a "getter", which is not always desired. What you're interested in is that Employee's email was updated:
$employee->updateEmail(new Email('new#email.com'))->shouldBeCalled();
The same can be achieved with spies if you prefer:
$employee->updateEmail(new Email('new#email.com'))->shouldHaveBeenCalled();
Command/Query Separation
We usually only need to state our expectations against methods that have side effects (command methods from Command/Query separation). We mock them.
Query methods do not need to be mocked, but stubbed. You don't really expect that EmployeeRepository::employeeWithUsername() should be called. Doing so we're making assumptions about implementation which in turn will make refactoring harder. All you need is stubbing it, so if a method is called it returns a result:
$employeeRepository->employeeWithUsername(new EmployeeUsername(self::USERNAME))
->willReturn($employee);
Full example
class EmployeeCommandHandlerSpec extends ObjectBehavior
{
const USERNAME = 'johnny';
public function let(EmployeeRepository $employeeRepository)
{
$this->beConstructedWith($employeeRepository);
}
public function it_changes_the_employee_email(
EmployeeRepository $employees, Employee $employee
) {
$this->givenEmployeeExists($employees, $employee);
$this->changeEmail(
new ChangeEmailCommand(self::USERNAME, 'new#email.com')
);
$employee->changeEmail(new Email('new#email.com'))->shouldHaveBeenCalled();
}
private function givenEmployeeExists(
EmployeeRepository $employees, Employee $employee
) {
$employees->employeeWithUsername(new EmployeeUsername(self::USERNAME))
->willReturn($employee);
}
}
I am trying to test methods from the following class I have written (there are more functions than what is shown, basically, one function for each is_*() method):
class Validate {
private static $initialized = false;
/**
* Construct won't be called inside this class and is uncallable from the outside. This prevents
* instantiating this class. This is by purpose, because we want a static class.
*/
private function __construct() {}
/**
* If needed, allows the class to initialize itself
*/
private static function initialize()
{
if(self::$initialized) {
return;
} else {
self::$initialized = true;
//Set any other class static variables here
}
}
...
public static function isString($string) {
self::initialize();
if(!is_string($string)) throw new InvalidArgumentException('Expected a string but found ' . gettype($string));
}
...
}
When I test if the methods throw an exception on invalid input, it works great! However, when I test if the method works as expected, PHPUnit complains because I have no assert in the test. The specific error is:
# RISKY This test did not perform any assertions
However, I don't have any value to assert against so I'm not sure how to overcome this.
I've read some about testing static methods, but that mostly seems to cover dependencies between static methods. Further, even non-static methods could have no return value, so, how to fix this?
For reference, my test code:
class ValidateTest extends PHPUnit_Framework_TestCase {
/**
* #covers ../data/objects/Validate::isString
* #expectedException InvalidArgumentException
*/
public function testIsStringThrowsExceptionArgumentInvalid() {
Validate::isString(NULL);
}
/**
* #covers ../data/objects/Validate::isString
*/
public function testIsStringNoExceptionArgumentValid() {
Validate::isString("I am a string.");
}
}
Test void function with assertNull:
/**
* #covers ../data/objects/Validate::isString
*/
public function testIsStringNoExceptionArgumentValid() {
$this->assertNull( Validate::isString("I am a string.") );
}
To prevent the warning about the assertions you can use the #doesNotPerformAssertions annotation as explained in the documentation: https://phpunit.de/manual/current/en/appendixes.annotations.html#idp1585440
Or if you prefer code over annotation:
$this->doesNotPerformAssertions();
One solution I have come upon is the following, based on example 2.12 from chapter 2 of PHPUnit. It feels a little hacky to me, but it's the best I've found so far. Also, based on this PHPUnit Gitub issue discussion, it seems several other people want this feature but that there are no plans to implement it.
Change testIsStringNoExceptionArgumentValid() to the following:
/**
* #covers ../data/objects/Validate::isString
*/
public function testIsStringNoExceptionArgumentValid() {
try {
Validate::isString("I am a string.");
} catch (InvalidArgumentException $notExpected) {
$this->fail();
}
$this->assertTrue(TRUE);
}
If you want to test a void function you only need to run it without any assertion.
If it there is any issue it will throw an exception and test will fails. No need to put $this->assertTrue(TRUE); as you are not running an assertion and having assertions is not required to test your code.
You will get a message like
Time: 7.39 seconds, Memory: 16.00 MB
OK (1 test, 0 assertions)
Process finished with exit code 0
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.