Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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 Response object.
I want to be able to unit test a controller in isolation.
How do you do it?
Is the answer to create a controller as a Plain Old PHP Object, register it as a service and use Dependency Injection to pass a new Response object (or a Response factory) into it?
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: