Added some functional tests for the backend #23
Conversation
| $this->assertEquals( | ||
| Response::HTTP_FORBIDDEN, | ||
| $client->getResponse()->getStatusCode(), | ||
| 'Regular users cannot access to the backend.' |
There was a problem hiding this comment.
is it really needed to repeat the method name in the error message? You can use phpunit --testdox to see these messages nicely already.
There was a problem hiding this comment.
I agree with you. I've just removed the redundant messages. Thanks.
| $crawler = $client->request('GET', '/admin/post/'); | ||
|
|
||
| $this->assertCount( | ||
| Post::NUM_ITEMS, |
There was a problem hiding this comment.
what if there is less elements on the DB ? this would make the test fail. the last page of the pagination may have less items
There was a problem hiding this comment.
I've just updated the application to include a separate database for tests, which is in fact the good practice that people should follow.
| # fixed and known set of data fixtures, it simplifies the code of tests and it | ||
| # makes them more robust. | ||
| # In this case we just define a different path for the application database, | ||
| # but you can even use an entirely database engine for tests. |
There was a problem hiding this comment.
using a different database engine should not be recommended IMO: some of your queries might depend on the engine being used, and would not work on the other.
Even if you rely on Doctrine only and never write SQL yourselves, it may have platform-specific bugs (especially on platforms being less tested like SqlServer or Oracle), for instance when paginating complex queries (there is a huge work in the ORM currently to make the pagination actually work on complex queries). And some features are simply not supported on some platforms
|
should we really commit the test DB ? The day you write a functional test for non-safe requests, this will hurt you |
|
Yes, I think we should commit the test DB to meet our promise: "everything works perfectly out-of-the-box". ("everything" means frontend, backend and tests ... and "out-of-the-box" means: 0 questions to answer, 0 options to provide, 0 commands to execute and 0 config changes). |
|
@javiereguiluz we also recommend following best practices. and commiting a DB does not look like a best practice. It can hurt your workflow quickly (you will also need to update it when changing your doctrine schema btw, which may create wunky git conflicts because of being a binary file). A much better setup IMO is making the test self-contained by making it load the necessary content in the test DB. |
|
I understand you now. You are right. We'll load the fixtures dynamically in the test in a future pull request. But before I'm waiting for this old Symfony doc issue to be completed: symfony/symfony-docs#480 but it seems nobody wants to work on it :( |
This allows to explain how to test resources protected by a firewall and the trick to change the firewall configuration just for the test environment.