E2E testing

This article covers some helpful strategies when setting up end-to-end (E2E) tests on top of Stytch-powered authentication flows. You'll learn how to:

Set up automated tests for different authentication products
Generate Stytch session tokens or JWTs
Avoid Stytch rate limits when testing

Automated tests for passwordless authentication flows

You may need to complete a passwordless authentication flow during some of your automated tests. In order to accomplish this, we generally recommend using a platform like Mailosaur to set up a programmatically accessible email or SMS inbox.

Two of our engineers discussed passwordless E2E testing at a recent Cypress conference:

You can find the repository that accompanies the above talk here.

Note that OAuth in particular is generally not compatible with E2E testing, given that OAuth providers (like Google) do not allow you to log in via browser automation. If you offer OAuth in your application, we recommend using an alternative authentication product in your E2E tests.

Bypassing Email Magic Links bot detection

We have a bot detection mechanism built into our Email Magic Links flow that prevents email security bots from following and invalidating your users' Magic Link tokens. For additional information, see our Protected Magic Links resource.

You may run into this bot protection when setting up automated Email Magic Links or Password reset by email tests. Below is a strategy that will allow your tests to proceed by bypassing the redirect to the Stytch-hosted page where bot detection runs:

1Extract the Magic Link query parameters

Instead of following the Magic Link URL from Email Magic Links emails directly, extract only the query parameters from the URL. For example, the Magic Link included in the email will look something like this: https://test.stytch.com/v1/magic_links/redirect?public_token=YOUR_PUBLIC_TOKEN&slug=SLUG&stytch_token_type=multi_tenant_magic_links&token=TOKEN_VALUE. You'd extract the query parameters only: public_token=YOUR_PUBLIC_TOKEN&slug=SLUG&stytch_token_type=multi_tenant_magic_links&token=TOKEN_VALUE.

Add those query parameters to your own login or signup redirect URL, and then redirect directly to that URL instead. For example, If your login URL were https://yourdomain.com/yourloginpath, you'd redirect to https://yourdomain.com/yourloginpath?public_token=YOUR_PUBLIC_TOKEN&slug=SLUG&stytch_token_type=multi_tenant_magic_links&token=TOKEN_VALUE during your automated tests.

Here's example code that demonstrates the above strategy:

function formatMagicLink(
  magicLinkFromEmail: string,
  loginRedirectUrl: string
): string {
  const queryParameters = new URL(magicLinkFromEmail).searchParams.toString();
  return `${loginRedirectUrl}?${queryParameters}`;
}

Generating a Stytch session token or session JWT

Sometimes, you'll need to generate a Stytch session token or JWT for use in E2E tests that aren't intended to test your login flow itself.

For this use case, a common strategy is to leverage passwords for testing purposes, even if you don't use our Passwords product as part of your production login flow:

Create a test Member in a test Organization, and add a password to the Member.
At the beginning of each test that requires a Stytch session token or JWT, call the Authenticate password endpoint with the test email_address and password values from the previous step.
Retrieve the session_token or session_jwt value from the Authenticate password response for use in the rest of your test.

Avoiding rate limits

We have rate limits built into our API in order to protect our endpoints from malicious traffic (see our Rate limits resource for additional information). You may run into certain rate limits depending on how frequently you run your E2E tests and which Stytch endpoints you're calling.

In order to avoid hitting Stytch rate limits, we recommend running your tests using your Stytch Test project keys whenever possible. Our Test environment is built to support iteration and testing, and has different rate limits than our Live environment.