From dd4b2c38eb409c9f58953102e8cd7d935480d0b9 Mon Sep 17 00:00:00 2001 From: Christoph Rumpel Date: Thu, 2 Apr 2020 16:51:41 +0200 Subject: [PATCH 1/4] Mention new assertions assertNotSent and assertNothingSent --- http-client.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/http-client.md b/http-client.md index c5045009583..310a44f3724 100644 --- a/http-client.md +++ b/http-client.md @@ -265,3 +265,24 @@ The `assertSent` method accepts a callback which will be given an `Illuminate\Ht $request['name'] == 'Taylor' && $request['role'] == 'Developer'; }); + +Besides that you can also expect that a specific request was not sent by using `assertNotSent`: + + Http::fake(); + + Http::post('http://test.com/users', [ + 'name' => 'Taylor', + 'role' => 'Developer', + ]); + + Http::assertNotSent(function (Request $request) { + return $request->url() === 'http://test.com/posts'; + }); + +And if you want to make sure no request was sent at all, you can make use of `assertNothingSent`: + + Http::fake(); + + Http::assertNothingSent(); + + From 21bd07ef9ed74243e841766ca01ef530fb347772 Mon Sep 17 00:00:00 2001 From: Dries Vints Date: Fri, 3 Apr 2020 14:29:25 +0200 Subject: [PATCH 2/4] Add testing part to Cashier docs --- billing.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/billing.md b/billing.md index c200dadb4b6..179d9ba68f4 100644 --- a/billing.md +++ b/billing.md @@ -47,6 +47,7 @@ - [Payments Requiring Additional Confirmation](#payments-requiring-additional-confirmation) - [Off-session Payment Notifications](#off-session-payment-notifications) - [Stripe SDK](#stripe-sdk) +- [Testing](#testing) ## Introduction @@ -928,3 +929,22 @@ Many of Cashier's objects are wrappers around Stripe SDK objects. If you would l $stripeSubscription = $subscription->asStripeSubscription(); $stripeSubscription->update(['application_fee_percent' => 5]); + + +## Testing + +When it comes to testing your app integration with Cashier you have two options. Mocking or performing actual HTTP requests to the Stripe API. Mocking has the benefit of making your tests fast but has the downside that you'll have to partially re-implement Cashier's behavior. Using the Stripe API has the benefit of avoiding bugs and unexpected scenarios but will make your tests run slowly. You can choose one approach or a combination of both. Either way, you should know that Cashier itself already has a very good test suite so you should only focus on testing the subscription & payment flow of your app, and not of every underlying Cashier behavior. + +What we recommend is to make use of the actual Stripe API because it's the only way of really knowing that your calls were successful or not. Like said before, it'll slow down your tests a lot so you want to put these in one or multiple separate classes so you can only run these occassionally. + +To get started, add your `STRIPE_SECRET` **testing** key to your `phpunit.xml`: + + + +Now, whenever you execute Cashier calls in your app, it'll send real API requests to your Stripe testing account. + +As for fixtures, you can either choose to pre-fill your testing account with some plans which you can use for testing or you can create these on the fly when running your tests (but this will slow down your tests even more). [Cashier's own Integration test suite](https://github.com/laravel/cashier/tree/10.0/tests/Integration) takes the latter approach which you can use for inspiration for your own tests. + +### stripe-mock + +Stripe is currently developing a library called ["stripe-mock"](https://github.com/stripe/stripe-mock) which will allow to mock these expensive HTTP calls when testing. Unfortunately the library currently is stateless and Cashier relies on persisted state in Stripe a lot. When this library eventually implements persistence, we'll update Cashier's own test suite and update these docs so you can make use of it. From f5334d6576a83515d26a9090e5a7cb61d67c3a78 Mon Sep 17 00:00:00 2001 From: Taylor Otwell Date: Fri, 3 Apr 2020 08:59:10 -0500 Subject: [PATCH 3/4] Update http-client.md --- http-client.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/http-client.md b/http-client.md index 310a44f3724..25dfc007a39 100644 --- a/http-client.md +++ b/http-client.md @@ -266,7 +266,7 @@ The `assertSent` method accepts a callback which will be given an `Illuminate\Ht $request['role'] == 'Developer'; }); -Besides that you can also expect that a specific request was not sent by using `assertNotSent`: +If needed, you may assert that a specific request was not sent using the `assertNotSent` method: Http::fake(); @@ -279,10 +279,8 @@ Besides that you can also expect that a specific request was not sent by using ` return $request->url() === 'http://test.com/posts'; }); -And if you want to make sure no request was sent at all, you can make use of `assertNothingSent`: +Or, if you would like to assert that no requests were sent, you may use the `assertNothingSent` method: Http::fake(); Http::assertNothingSent(); - - From d6050694a5f1293d339edaf7ad9e494eb8ade26e Mon Sep 17 00:00:00 2001 From: Taylor Otwell Date: Fri, 3 Apr 2020 09:32:27 -0500 Subject: [PATCH 4/4] formatting --- billing.md | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/billing.md b/billing.md index 179d9ba68f4..3852eea2d09 100644 --- a/billing.md +++ b/billing.md @@ -933,18 +933,12 @@ Many of Cashier's objects are wrappers around Stripe SDK objects. If you would l ## Testing -When it comes to testing your app integration with Cashier you have two options. Mocking or performing actual HTTP requests to the Stripe API. Mocking has the benefit of making your tests fast but has the downside that you'll have to partially re-implement Cashier's behavior. Using the Stripe API has the benefit of avoiding bugs and unexpected scenarios but will make your tests run slowly. You can choose one approach or a combination of both. Either way, you should know that Cashier itself already has a very good test suite so you should only focus on testing the subscription & payment flow of your app, and not of every underlying Cashier behavior. +When testing an application that uses Cashier, you may mock the actual HTTP requests to the Stripe API; however, this requires you to partially re-implement Cashier's own behavior. Therefore, we recommend allowing your tests to hit the actual Stripe API. While this is slower, it provides more confidence that your application is working as expected and any slow tests may be placed within their own PHPUnit testing group. -What we recommend is to make use of the actual Stripe API because it's the only way of really knowing that your calls were successful or not. Like said before, it'll slow down your tests a lot so you want to put these in one or multiple separate classes so you can only run these occassionally. +When testing, remember that that Cashier itself already has a great test suite, so you should only focus on testing the subscription and payment flow of your own application and not every underlying Cashier behavior. -To get started, add your `STRIPE_SECRET` **testing** key to your `phpunit.xml`: +To get started, add the **testing** version of your Stripe secret to your `phpunit.xml` file: -Now, whenever you execute Cashier calls in your app, it'll send real API requests to your Stripe testing account. - -As for fixtures, you can either choose to pre-fill your testing account with some plans which you can use for testing or you can create these on the fly when running your tests (but this will slow down your tests even more). [Cashier's own Integration test suite](https://github.com/laravel/cashier/tree/10.0/tests/Integration) takes the latter approach which you can use for inspiration for your own tests. - -### stripe-mock - -Stripe is currently developing a library called ["stripe-mock"](https://github.com/stripe/stripe-mock) which will allow to mock these expensive HTTP calls when testing. Unfortunately the library currently is stateless and Cashier relies on persisted state in Stripe a lot. When this library eventually implements persistence, we'll update Cashier's own test suite and update these docs so you can make use of it. +Now, whenever you interact with Cashier while testing, it will send actual API requests to your Stripe testing environment. For convenience, you should pre-fill your Stripe testing account with subscriptions / plans that you may then use during testing.