Cannot use in (offline) tests

[jamesarosen]

In test mode (at least in environments without networking), the <script> tag that this addon injects won't run and Stripe won't be defined. That means Stripe.setPublishableKey won't exist and the initializer will fail.

The smallest change I can think of that would work (which I've used locally successfully) is

// app/services/stripe.js
function createToken (card) {
  Ember.assert("Cannot create Stripe token in test environment", config.environment !== 'test');
  // ...
}

// app/initializers/stripe-service.js
export function initialize() {
  if (config.environment === 'test') { return; }
  // ...
}

This isn't perfect, but it's pretty good. I end up stubbing out stripe.createToken whenever I need to actually run that function, with without a standard stubbing library, I can't think of a good way of doing this here.

[jamesarosen]

An alternative would be to include a version of stripe.js in this library and use the following pattern:

<script type="text/javascript" src="https://js.stripe.com/v2/"></script>
<script>
(function() {
if (typeof Stripe === 'undefined') {
  var head = document.getElementsByTagName("head")[0];
  var script = document.createElement('script');
  script.type = 'text/javascript';
  script.src = 'path/to/stripe.js';
  head.appendChild(script);
}
}());
</script>

Unfortunately, I don't know of a way to get path/to/stripe.js in the Broccoli tree without also making this a Bower component.

[buritica]

Thanks @jamesarosen, we have had no issues with headless tests. Does this happen with offline tests, or it happens even when you have connection? If it's offline then, you would indeed get errors since Stripe is only meant to be included from Stripe's servers, we don't bundle the source of the library for this reason.

We've thought about mocking Stripe in test environment, but have not done it yet. I may take a stab at it this week to make your life easier.

[jamesarosen]

I was seeing the problem in my headless PhantomJS tests, but not in the Chrome tests. It could have been an offline-only problem that was masked by caching in Chrome.

I do develop in places without a network, though. I'm happy with any solution -- bundling, stubbing, or simply aborting the initializer -- that works in that situation.

[jamesarosen]

In the meantime, I've added

import config from '../config/environment';

// The ember-stripe-service add-on relies on Stripe being
// defined. In offline mode, we won't have fetched the real
// stripe.js, so Stripe will be undefined and the add-on's
// initializer will break.
//
// See https://github.com/ride/ember-stripe-service/issues/12
export default {
  name: 'fake-stripe',
  before: 'stripe',

  initialize: function() {
    if (config.environment !== 'test') { return; }
    if (typeof Stripe !== 'undefined') { return; }

    window.Stripe = {
      setPublishableKey: function() {},
      card: { createToken: function() {} }
    };
  }
};

so we can continue development. I'm looking forward to seeing what you come up with :)

[buritica]

Hey @jamesarosen I'll be having a look at this over the weekend, suddenly got quite busy this week.

[jme783]

+1

[ryanlitalien]

@buritica I'm running into this problem as well. @jamesarosen 's fake-stripe fix worked well for our project running CI on Codeship. Any ballpark estimate on a proper fix?

[buritica]

Hey @ryanlitalien, haven't had a lot of time to dedicate to this add-on, will probably look at it over the next couple weeks.

[ryanlitalien]

@buritica Thanks, subscribed :)

[joshsmith]

@jamesarosen I've used the pattern you used in the past to fake the service out in tests (which also allows me to potentially hook into the interface to make even testing receipt of certain data testable).

Do you think this needs to be part of the library or left as an implementation detail to the developer (with maybe some usage documentation explaining what to do)?

[jamesarosen]

I know some libraries will provide test support in their addon/ folder and include those files in the broccoli tree only in the test environment. You could provide an addon/fake-stripe.js without autoinstalling it.

[davewasmer]

I'd suggest that the initializer should also be robust to Stripe.js failing to load. If Stripe's JS CDN goes down for whatever reason, that shouldn't also take my entire app with it.