Test Fixtures

dj-stripe’s unit tests rely on fixtures to represent Stripe API and webhook data.


These fixtures are partly hand-coded and partly generated by creating objects in Stripe and then retrieved via the API.

Each approach has pros and cons:

Hand-coding the fixtures allows them to be crafted specifically for a test case. They can also be terse, and nested objects can be done by reference to avoid duplication. But maintaining or upgrading them is a painstaking manual process.

Generating the fixtures via Stripe gives the big advantage that Stripe schema changes are automatically represented in the fixtures, which should allow us to upgrade dj-stripe’s schema to match Stripe much more easily. This would be done by updating dj-stripe’s targeted API version (DEFAULT_STRIPE_API_VERSION), regenerating the fixtures, and updating the model to match the fixture changes. The down side is it’s tricky to regenerate fixture files without introducing big changes (eg to object ids) - the script does this by mapping a dummy id to various objects.

Regenerating the test fixtures

To regenerate the test fixtures (e.g. to populate the fixtures with new API fields from Stripe), do the following:

  1. (one time only) Create a new Stripe account called “dj-stripe scratch”, with country set to United States. (we use US so the currency matches the existing fixtures matches, in the future it would be good to test for other countries).

  2. If you already had this account ready and want to start again from scratch, you can delete all of the test data via the button in Settings > Data https://dashboard.stripe.com/account/data

  3. Activate a virtualenv with the dj-stripe project (see Getting Started)

  4. Set the dj-stripe secret key environment variable to the secret key for this account (export STRIPE_SECRET_KEY=sk_test_...)

  5. Run the manage command to create the test objects in your stripe account if they don’t already exist, and regenerate the local fixture files from them:

    $ ./manage.py regenerate_test_fixtures

The command tries to avoid inconsequential changes to the fixtures (e.g the created timestamp) by restoring a whitelist of values from the existing fixtures.

This functionality can be disabled by passing the parameter –update-sideeffect-fields.