| # |
Jul 13th 2017, 19:40 |
jarard01 |
something like: $e->query->contain(['Offers']); |
| # |
Jul 13th 2017, 19:39 |
jarard01 |
how do i add a contain to the beforeFind of the CRUD plugin |
| # |
Jul 13th 2017, 18:24 |
hmic |
so you know where to look at |
| # |
Jul 13th 2017, 18:23 |
 ericadeefox |
in the tests for the sdk itself, they do exactly what I tried to do, in my own tests, to recreate the plugin's behavior--and yet for some reason kept getting exceptions thrown at me |
| # |
Jul 13th 2017, 18:21 |
hmic |
build a mock. |
| # |
Jul 13th 2017, 18:21 |
mikesmoniker |
I’m afraid I’m not familiar with either of those libs, but I’d expect there to be something you can swap out (via config or dependency inversion) to test *your* code without actually modifying said code. |
| # |
Jul 13th 2017, 18:21 |
ericadeefox |
again, I know, I wouldn't be asking if I had found a way to successfully recreate this plugin's behavior. |
| # |
Jul 13th 2017, 18:20 |
hmic |
ericadeefox: it should not. you should mock the things that need special handling during tests. NOT implement different behavior during testing! |
| # |
Jul 13th 2017, 18:20 |
mikesmoniker |
Have you looked at the tests for the plugin and SDK themselves to see how they might approach a similar problem? |
| # |
Jul 13th 2017, 18:19 |
ericadeefox |
since the thing I'm verifying *does* behave conditionally depending on whether it's being tested, it seems appropriate. I am so spent on Facebook's SDK. it screwed up 100% of my integration tests. |
| # |
Jul 13th 2017, 18:18 |
ericadeefox |
I know. I just have no idea what else to do at this point. |
| # |
Jul 13th 2017, 18:04 |
mikesmoniker |
Ideally you wouldn’t do that because then the thing you’re supposed to be verifying the behavior of has it’s behavior conditional upon whether it’s being tested. |
| # |
Jul 13th 2017, 17:58 |
ericadeefox |
ok new strategy: has anyone ever needed to write an if statement in their app controller that checked whether or not PHPUnit was running or if tests were running etc? |
| # |
Jul 13th 2017, 17:39 |
chris-andre |
Collection::filter(), does anyone know what `$key` is good for in the docs example? https://book.cakephp.org/3.0/en/core-libraries/collections.html#Cake\Collection\Collection::filter |
| # |
Jul 13th 2017, 15:18 |
ericadeefox |
has anyone on here today got experience with @akkaweb's Facebook plugin or just using Facebook's php-sdk in general? |
| # |
Jul 13th 2017, 15:15 |
sauvaget |
Thanks! |
| # |
Jul 13th 2017, 15:12 |
sauvaget |
I'll have a look into that |
| # |
Jul 13th 2017, 15:12 |
sauvaget |
cool |
| # |
Jul 13th 2017, 15:09 |
cleptric |
Mark recommended https://github.com/php-vcr/php-vcr if you want to test against external APIs |
| # |
Jul 13th 2017, 15:08 |
sauvaget |
So I'll start researching how to write a Unittest for my tasks |
| # |
Jul 13th 2017, 15:07 |
sauvaget |
Although I don't really care about how long they run |
| # |
Jul 13th 2017, 15:07 |
sauvaget |
Haha okay ;) |
| # |
Jul 13th 2017, 15:07 |
neon1024 |
Well I mean, that’s what I would do ;) |
| # |
Jul 13th 2017, 15:07 |
neon1024 |
@sauvaget If you’re running tests on push, then I would stick to critical path unit tests. Integration tests take a long time to run |
| # |
Jul 13th 2017, 15:06 |
johnwayne |
@ericadeefox and @neon1024 thank you I will take a look tommorow, thank you for the tips :slightly_smiling_face: |
| # |
Jul 13th 2017, 15:06 |
sauvaget |
I think that is probably my main problem, I just haven't got enough experience, when to use which testing method |
| # |
Jul 13th 2017, 15:05 |
sauvaget |
So I should abort the Integration Test completly and only write Unittests or can I somehow inject the mocked class into my integration test? |
| # |
Jul 13th 2017, 14:55 |
neon1024 |
I like to write my CakePHP helpers in a TDD way to keep my hand in :P |
| # |
Jul 13th 2017, 14:55 |
neon1024 |
Which then ties into writing ‘testable code’, which helps loads. Especially if you respect the SOLID principles |
| # |
Jul 13th 2017, 14:54 |
neon1024 |
At least in my experience ;) |
| # |
Jul 13th 2017, 14:54 |
neon1024 |
Keeping your unit under test as small as possible will make writing tests super easy |
| # |
Jul 13th 2017, 14:53 |
neon1024 |
By having your stub MailGun class return a 500 or something |
| # |
Jul 13th 2017, 14:53 |
neon1024 |
You might want to test the third party service failing |
| # |
Jul 13th 2017, 14:53 |
neon1024 |
As all you can really test is that you send a request |
| # |
Jul 13th 2017, 14:52 |
neon1024 |
But if you’re using a third party to send mail, it’s pretty pointless to test it |
| # |
Jul 13th 2017, 14:52 |
neon1024 |
In this case to unit test your email send, you would inject a mock Mailgun class which has a fixed return |
| # |
Jul 13th 2017, 14:51 |
neon1024 |
That is not unit testing, that is integration testing. |
| # |
Jul 13th 2017, 14:50 |
slackebot |
That's why I thought testing the tasks directly would do the trick. |
| # |
Jul 13th 2017, 14:50 |
sauvaget |
Okay, but for example in my QueueShellTest I create the Job SendEmail and start the worker with ``` $this->QueueShell->runworker(); ``` It will do everything fine. Now for sending the Email I use Mailgun. I don't really want to call the Mailgun API every time I run my Unittests (which run with every push to gitlab) So I will have to Mock the method in my SendEMail Task. But since I am not testing the Task directly I don't know how to Mock th |
| # |
Jul 13th 2017, 14:50 |
sturm |
Wait; nevermind. I totally didn’t check the Add and Edit pages. |
| # |
Jul 13th 2017, 14:49 |
sturm |
Working on the final part, “Improving the Tagging Experience,” and I don’t see what the changes have done. I don’t see the list of tags as a string anywhere. |