# |
Jul 5th 2017, 23:04 |
jeremyharris |
indeed! and since they are dropped and re-created on each test case, you always know what state your DB is in at the start of each test |
# |
Jul 5th 2017, 23:04 |
urowe |
I hand't really understood how they worked |
# |
Jul 5th 2017, 23:03 |
urowe |
Oh that's very cool |
# |
Jul 5th 2017, 23:03 |
jeremyharris |
so you would need a UsersFixture and a RolesFixture. Whatever records exist in those fixtures would be loaded on each test case. Then you can call your app code that does the check, and it will read from the test database (now populated with those records) |
# |
Jul 5th 2017, 23:02 |
urowe |
In case let's say I want to verify a user has a role that already exists in the database |
# |
Jul 5th 2017, 23:02 |
jeremyharris |
the fixtures in cakephp set up your database state on each test method, that’s all |
# |
Jul 5th 2017, 23:02 |
jeremyharris |
you can use a test method with a dataProvider side by side with fixtures - they work fine together |
# |
Jul 5th 2017, 23:01 |
urowe |
Oh, so I can have some fixed values, let's say roles and have tests to run with dataProvider methods for users? |
# |
Jul 5th 2017, 23:01 |
jeremyharris |
if you’re familiar with database testing in vanilla phpunit, it’s similar to that process: https://phpunit.de/manual/current/en/database.html |
# |
Jul 5th 2017, 22:59 |
jeremyharris |
before each test method is run |
# |
Jul 5th 2017, 22:58 |
jeremyharris |
yep |
# |
Jul 5th 2017, 22:58 |
urowe |
Let me see if I understand this, fixtures are loaded to the test database before tests are run? |
# |
Jul 5th 2017, 22:58 |
jeremyharris |
the table will fetch from the test database rather than the live one, assuming you have it configured correctly and your test bootstrap is correct (ships with cakephp/app) |
# |
Jul 5th 2017, 22:57 |
jeremyharris |
if you want to get a user from the fixture during a test case, simply use TableRegistry::get(‘Users’)->get($userId) |
# |
Jul 5th 2017, 22:57 |
urowe |
Aren't they redundant ? |
# |
Jul 5th 2017, 22:57 |
jeremyharris |
I’m not sure what you mean. dataProvider and fixtures are two different things. |
# |
Jul 5th 2017, 22:57 |
urowe |
Is there any way to stop the call from where it happens and have these records from a dataProvider method? |
# |
Jul 5th 2017, 22:56 |
jeremyharris |
for example, if you have UsersFixture that has some test user records in it. and you delete a user in a test case, on the next test case, the user would exist again — you have a fresh database to test with. this allows you to write predictable tests against the database because you always know what the database will look like (fixtures) on each test case |
# |
Jul 5th 2017, 22:55 |
jeremyharris |
they are dropped on each test, so your test database is fresh on each test case |
# |
Jul 5th 2017, 22:54 |
jeremyharris |
urowe a fixture file is a list of records that is inserted into the test database configuration, usually with $this->loadFixtures |
# |
Jul 5th 2017, 22:43 |
jarard01 |
I am setting the template for a form on the fly on my controller, but the same code template is used b severla methods, how can I call it globally |
# |
Jul 5th 2017, 22:37 |
urowe |
Hi guys, I don't really understand how fixtures are used in unit tests, like I'm not even calling them anywhere and they are saved and stuff, are they like dataproviders in phpunit? |
# |
Jul 5th 2017, 22:05 |
jeremyharris |
any time :slightly_smiling_face: |
# |
Jul 5th 2017, 22:03 |
origamiwork |
Thanks for the help. I wouldn't have thought about the iteration by myself for a while. |
# |
Jul 5th 2017, 22:03 |
jeremyharris |
hehe roll with it |
# |
Jul 5th 2017, 22:02 |
origamiwork |
Yay, I got it. It was something dumb as I thought. I was only expecting one result in the view, so I wasn't actually iterating on the passed object. (I'll use the fact that I haven't worked with cake in a long time as my excuse :D ) |
# |
Jul 5th 2017, 21:59 |
jeremyharris |
or since they’re so short, gist the action and view and I can give you a second pair of eyes |
# |
Jul 5th 2017, 21:59 |
jeremyharris |
to see what it’s getting. I stand by my suggestion to use debug kit :slightly_smiling_face: |
# |
Jul 5th 2017, 21:58 |
jeremyharris |
you can try debug($this->viewVars) on the view |
# |
Jul 5th 2017, 21:58 |
origamiwork |
the controller is pretty short too. I think it might just be something obvious I'm missing. |
# |
Jul 5th 2017, 21:57 |
jeremyharris |
:) easy to read then |
# |
Jul 5th 2017, 21:56 |
origamiwork |
no, that wouldn't be it, the view is only 4 lines long |
# |
Jul 5th 2017, 21:55 |
jeremyharris |
perhaps you’re overwriting it somewhere earlier in the view? |
# |
Jul 5th 2017, 21:55 |
origamiwork |
hmmm... strange, it wasn't finding anything. It must be some stupid small error I'm making somewhere. |
# |
Jul 5th 2017, 21:55 |
jeremyharris |
if you use debug kit, you can inspect what variables the view is getting |
# |
Jul 5th 2017, 21:55 |
jeremyharris |
yep! that’s usually how it is done |
# |
Jul 5th 2017, 21:54 |
origamiwork |
Should I be able to pass a query object to a view? I was passing the results of the magic findBy function to a view and iterating through them there, but it wasn't able to find any of the variables. |
# |
Jul 5th 2017, 21:53 |
origamiwork |
Awesome, thanks. |
# |
Jul 5th 2017, 21:50 |
jeremyharris |
(for future ref) |
# |
Jul 5th 2017, 21:50 |
jeremyharris |
if you want to inspect the results without iterating through them, you can use ->toArray() |
# |
Jul 5th 2017, 21:49 |
origamiwork |
@slackebot Thanks for the info, I was actually using that link to write my code. I think what you said about iterating is working. When I loop through the results using foreach, it seems to have the correct data. |