Issues when testing locally
Loots-it opened this issue · 6 comments
Hi
I'm wondering how you guys are testing the integration with cashier-mollie in your own projects?
I would like to use Laravel dusk tests and the 'regular' Laravel tests. But I ran into issues because of the webhooks. I don't want to provide Mollie any webhooks while testing because Mollie can't reach my localhost (obviously) and will complain. My idea was that I make the webhook_url and first_payment.webhook_url null and call the webhook myself after the payments has completed (or failed). But this is not possible because the method setFirstPaymentWebhookUrl in vendor/laravel/cashier-mollie/src/Plan/Plan.php:260 doesn't accept null values.
I could provide a real absolute URL for testing but this would feel odd. I know it's also possible to use something ngrok but this also feels like a workaround. I think it would make sense if we could configure the webhook to be null as this value is optional in the Mollie API. I understand that in production it doesn't make sense to do this so the defaults shouldn't change.
Do you know any better options for testing an integration with cashier-mollie? If that's the case maybe we could update the documentation?
I want to work on a pull request if the community agrees we need this feature.
You can try mocking the actions in src/Mollie. See the package tests for inspiration.
Thanks for your quick reply! Mocking the actions could be part of the solution, but this won't test the mocked actions themselves. To me, it seems safer to actually use the mollie test api for such a critical part of the application. Is there any way to make this work?
For mandated payments, you can make a POST request to your webhook with the payment id that was stored on the orders table.
For first payments, it will get tricky because you will need to have Dusk navigate through Mollie's checkout. Which I don't think will be really hard, but since the checkout is not under your control your tests will break if Mollie updates the checkout front-end.
So it's definitely doable but brittle by design. It depends on your use case what's the best approach here (partial tests or a bit brittle test).
Thanks again for your reply! I'm going for the 'bit brittle test', Mollie's test checkout isn't that hard to navigate through and if it changes it is easily debuggable. The only thing that still bothers me with this approach is that I have to use a 'fake webhook url' because null is not an option. I'm using my staging site for this, it's not really reachable from Mollie's point of view but the API isn't complaining.
I might also go for a different approach and generate bancontact payments via mollies php package, without 'real subscriptions'. The problem is that mandates obtained via bancontact aren't 'strong mandates' and if a customer asks a refund, they are almost always getting their money back, even without any good reason. At the moment I'm only working with yearly subscriptions so non recurring payments aren't a big issue.
Sounds great. One final option you have for the webhooks is to set up a small public app that hosts the required webhooks, captures the requests - that you can check using a REST API for example.
There are some public free services for that too but they tend to change the url periodically unless you pay - which may be worth it too.
Good luck!