beforeEach: function() {
      configure('async', customAsync);
      bb.begin();

      if (options.setup) {
        options.setup.apply(this, arguments);
      }
    },

function testConfigure() {
    assertType<void>(RSVP.configure('name', { with: 'some value' }));
    assertType<{}>(RSVP.configure('name'));
}

/* globals Promise */

import RSVP from 'rsvp';
import hasEmberVersion from './has-ember-version';

export class _Promise<T> extends RSVP.Promise<T> {}

const ORIGINAL_RSVP_ASYNC: Function = RSVP.configure('async');

/*
  Long ago in a galaxy far far away, Ember forced RSVP.Promise to "resolve" on the Ember.run loop.
  At the time, this was meant to help ease pain with folks receiving the dreaded "auto-run" assertion
  during their tests, and to help ensure that promise resolution was coelesced to avoid "thrashing"
  of the DOM. Unfortunately, the result of this configuration is that code like the following behaves
  differently if using native `Promise` vs `RSVP.Promise`:

  ```js
  console.log('first');
  Ember.run(() => Promise.resolve().then(() => console.log('second')));
  console.log('third');
  ```

  When `Promise` is the native promise that will log `'first', 'third', 'second'`, but when `Promise`
  is an `RSVP.Promise` that will log `'first', 'second', 'third'`. The fact that `RSVP.Promise`s can
  be **forced** to flush synchronously is very scary!

  Now, lets talk about why we are configuring `RSVP`'s `async` below...

  ---

  The following _should_ always be guaranteed: