Another benefit of my approach to testing Cashier

Yesterday, I shared how I test Cashier interactions in my Laravel apps.

Today, I want to go a step further and explain an additional benefit which extends beyond ease of testing.

First, it's important to note that my StripeService only includes methods that my application actually needs.

I resisted the urge to wrap the entire Cashier API "just in case" I might need in the future. I can always add methods as needed.

Why is this useful?

In the future, when Cashier has a major version update and introduces breaking changes with the Stripe API, I have fewer methods to review and fix. I can ignore breaking changes in methods I'm not using, and all my interactions are in one class for easy reference and update.

Also, you might decide that since you're only using a handful of methods from Cashier, it makes sense to remove the dependency and just use the Stripe SDK directly. Now you can do that without having to refactor your entire codebase.

This is a great real-world example of how making our application easier to test also leads us toward a slightly nicer design.

Here to help,

Joel

P.S. Have your own testing stories? We'd love to have you share in the Mastering Laravel community. This paid, private and vetted community has some of the most helpful and awesome programmers I've met. You should be there, too!