Added a tip about hardcoding URLs in functional tests #3592
Conversation
| Q | A |
|---|---|
| Doc fix? | no |
| New docs? | yes |
| Applies to | all |
| Fixed tickets | - |
| .. tip:: | ||
|
|
||
| Hardcoding the request URLs is a best practice for functional tests. If the | ||
| test generates URLS using the Symfony router, it won't detect any change |
| @@ -320,6 +320,12 @@ into your Symfony2 application:: | |||
| The ``request()`` method takes the HTTP method and a URL as arguments and | |||
| returns a ``Crawler`` instance. | |||
|
|
|||
| .. tip:: | |||
|
|
|||
| Hardcoding the request URLs is a best practice for functional tests. If the | |||
There was a problem hiding this comment.
I am not sure it is very clear. I think you can just also adjust a base url as a parameter and that should take care of things no?
There was a problem hiding this comment.
No, this is about the following scenario:
Your app has a "foo" route with the "/foo" path.
Your test generates the route using the "foo" route name, not the path.
Everything works and your users are very happy with you :)
2 months later, the new company intern changes the "foo" route and the new path is "/foooooooo"
The functional tests keep working, because routes are generated with the "foo" route name.
But the website is completely broken for the end users, because the "/foo" path no longer works
There was a problem hiding this comment.
but this is not the solution, the idea with route names relating to path is intended. Instead I think what we can be proposing is to lock a route to path test for functional, that locks this definition, if there is a change in any of the route map then it should fire up a warning to update the path on the functional test. no?
There was a problem hiding this comment.
@cordoval I'm afraid that I don't fully understand your alternative solution.
There was a problem hiding this comment.
it is simple, you mentioned that you may have a test
public function it_should_return_200()
{
// ...
$customCrawler = $this->visit('gush_go');
$this->assertEquals(self::OK, $customCrawler->getStatusCode());
}instead you would have an extra test:
/**
* @test
* This test was autogenerated by an extra command in GushBundle :D
*/
public function it_locks_my_routes()
{
// ...
$routes = [
'gush_go' => '/gush-go-go',
// ...
];
// some assert using the router asserting that a given route correspond to a given path
// ...
}just trying to think on your problem and how it could have been avoided.
There was a problem hiding this comment.
I think that only makes things much more difficult, @cordoval
Functional tests (acceptance tests actually) are created to test if the website works for the end user. Creating yet another Unit test to test if it works for the end user is a no go imo
There was a problem hiding this comment.
exactly we make things difficult for this newbie, and tests should flag red when she does something that she is not supposed to without updating the route properly. That is exactly the task for a good test. Notice for us that we know we can just generate this type of test automatically so it is totally easy to maintain such test.
There was a problem hiding this comment.
I don't think we follow eachother, @cordoval. It's easier for someone new to testing and Sf2 to use a hardcoded URL than to use the router to create a route.
|
Very very well-phrased :) |
…viereguiluz) This PR was merged into the 2.3 branch. Discussion ---------- Added a tip about hardcoding URLs in functional tests | Q | A | ------------- | --- | Doc fix? | no | New docs? | yes | Applies to | all | Fixed tickets | - Commits ------- b284e88 Fixed a minor typo 220e124 Added a tip about hardcoding URLS in functional tests