I want to use Test Driven Development as much as possible — it\'s a great way of working.
I am troubled by the fact that Symfony2 controllers create and return a new
Lewis - I thought I'd jump in here. The approach above has you replicating the better part of your actions logic in your tests. There's nothing wrong with this, many frameworks (notably RSPEC in Rails) actually suggest you perform both Unit tests on your Controller objects as well as functional tests. However, given your example, I think I'd skip the unit test and go for the functional approach.
The point of a test in my mind is to create a sandboxed environment, run the test, and check for side effects and direct result. If you get to a point where most of your test is isolating the method, then its probably time for either a different testing approach or a different approach to writing your class. Given that this is a controller, and by nature they glue together different pieces of the stack, I'd create your sandbox farther up the stack. Specifically, I would use an approach like this:
https://github.com/PolishSymfonyCommunity/SymfonyMockerContainer
Worked great for me :)
Normally, your controller plugs together different objects and connects them in the correct order. Maybe he calls a repository, reads some objects and returns them through the render method. Maybe he calls some other Handlers/Managers who do stuff.
This means that a controller is a high level component. More often than not this indicates that functional tests are in order instead of unit tests. You should not aim to get 100% code coverage with your unit tests. Maybe you can think of it that way: If you unit test everything the controller calls (model, validation, form, repository), what could go wrong? Most of the time it's something you only observe when using all the real classes involved when in production.
I want also like to point out that TDD does not mean that everything has to be unit-tested. It's ok to have some functional tests for the high-level code. As said, if you test the low-level components with unit-tests you should only test how they are working together which you cannot test with mocks because you tell the mocks what the return value is.
If your controller does more than plugging parts of the system together you should think about refactoring the stuff into more low-level classes you can test with unit-tests.
So my suggestion would be to use functional tests to test your controllers and use unit-tests to test your models and your business logic stuff.
If you struggle with functional tests, you can read the following:
Use mocks to isolate models and other objects from main controller method's logic, see http://www.phpunit.de/manual/3.7/en/test-doubles.html#test-doubles.mock-objects
I think that in older versions you could mock entire class, but with latest phpunit 3.6.10 that i have it doesn't seem to work. So i guess you are left with depency injection pattern
class objss{
function ss(){
$x = new zz();
var_dump($x->z());
}
}
class MoTest extends PHPUnit_Framework_TestCase{
public function setUp(){
}
public function testA(){
$class = $this->getMock('zzMock', array('z'), array(), 'zz');
$class->expects($this->any())->method('z')->will($this->returnValue('2'));
$obj = new objss();
$this->assertEquals('2', $obj->ss());
}
}
Refactor your controllers to be services: http://symfony.com/doc/current/cookbook/controller/service.html
Then you can easily unit test them.
Of course (as already mentioned by others) you can use the WebTestCase
as described here: http://symfony.com/doc/current/book/testing.html#functional-tests