You describe (in other tutorial) approach with loading mock data (using Alice and doctrine:fixtures:load) But in this tutorial when you write tests you load mock data inside each method, like:
public function testGETProgrammersCollectionPaginated()
{
for ($i = 0; $i < 25; $i++) {
$this->createProgrammer(array(
'nickname' => 'Programmer'.$i,
'avatarNumber' => 3,
));
}
}
Why you avoid to use Alice and doctrine:fixtures:load approach in this tutorial, I think it's much more clear? And second can we use Alice for test RESTfull APIs and is it much proper way then load mock data inside every test method?
Cool question :). There is no one, correct answer about this actually! The most important thing is this: at the start of each test, your database should be in a "known" state. And there are two philosophies for doing this:
A) Start each test with an empty database (or, at least, empty the tables that are relevant to the test) and then manually add whatever data you need right inside the test. This is the approach you see in this tutorial.
B) Start each test by loading some known fixtures, e.g. like Alice.
Approach (B) is a bit simpler, but it has 2 disadvantages:
1) It's a bit slower - you ultimately load a lot of fixtures that you might not need on that test. However, this can be overcome with some trick. For example, if you configured your test environment to use an SQLite database, then you could load all your fixtures once, then commit that final .db file. Then, at the beginning of each test, copy that .db file to the correct location so that your code uses. With this trick, you get a fresh database before each test... and all you needed to do was copy a single file.
2) Loading fixtures is a bit less clear. This is the bigger reason why I don't typically do this in tests. For example, if you have 25 programmers in your fixtures, then you could simply load your fixtures before the test, and everything would work great. But when you read the test... it's not so clear. I wonder, "why are there 25 users? Where are they coming from". When your data-loading code isn't right in your test, you lose some clarity.
I DO love fixtures - it's just a great way to have dummy data so that playing with your site is easy. But, I don't usually do it in tests... but that is not a 100% rule :).
"you ultimately load a lot of fixtures that you might not need on that test"?
You can simply load just one fixture file with only these 25 programmers in this test...then if you load just one file then it is easy to check quickly what is in this file ;)
Please, log in to vote for this comment
|
Share Comment
"Houston: no signs of life" Start the conversation!
This tutorial uses an older version of Symfony. The concepts of REST and serialization are still valid, but I recommend using API Platform in new Symfony apps.
4 Comments
Hi Ryan! Thanks for the great tutorial!
You describe (in other tutorial) approach with loading mock data (using Alice and doctrine:fixtures:load)
But in this tutorial when you write tests you load mock data inside each method, like:
Why you avoid to use Alice and doctrine:fixtures:load approach in this tutorial, I think it's much more clear?
And second can we use Alice for test RESTfull APIs and is it much proper way then load mock data inside every test method?
Yo Владимир Кривошапов!
Cool question :). There is no one, correct answer about this actually! The most important thing is this: at the start of each test, your database should be in a "known" state. And there are two philosophies for doing this:
A) Start each test with an empty database (or, at least, empty the tables that are relevant to the test) and then manually add whatever data you need right inside the test. This is the approach you see in this tutorial.
B) Start each test by loading some known fixtures, e.g. like Alice.
Approach (B) is a bit simpler, but it has 2 disadvantages:
1) It's a bit slower - you ultimately load a lot of fixtures that you might not need on that test. However, this can be overcome with some trick. For example, if you configured your test environment to use an SQLite database, then you could load all your fixtures once, then commit that final .db file. Then, at the beginning of each test, copy that .db file to the correct location so that your code uses. With this trick, you get a fresh database before each test... and all you needed to do was copy a single file.
2) Loading fixtures is a bit less clear. This is the bigger reason why I don't typically do this in tests. For example, if you have 25 programmers in your fixtures, then you could simply load your fixtures before the test, and everything would work great. But when you read the test... it's not so clear. I wonder, "why are there 25 users? Where are they coming from". When your data-loading code isn't right in your test, you lose some clarity.
I DO love fixtures - it's just a great way to have dummy data so that playing with your site is easy. But, I don't usually do it in tests... but that is not a 100% rule :).
Cheers!
Thanks a lot for your quick answer, you answered on my question!
"you ultimately load a lot of fixtures that you might not need on that test"?
You can simply load just one fixture file with only these 25 programmers in this test...then if you load just one file then it is easy to check quickly what is in this file ;)
"Houston: no signs of life"
Start the conversation!