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. The following table outlines our recommended testing strategy based on your test requirements:
| Tests that use... | Recommended testing strategy |
|---|---|
| Backend Stytch endpoints in a Test environment | Leveraging our sandbox values to trigger predetermined Stytch API responses |
| Frontend Stytch SDKs, any Stytch endpoints or methods in the Live environment, or behavior unique to specific Users or Sessions | Using a platform like Mailosaur to set up a programmatically accessible email or SMS inbox that you can use in your tests |
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.
Stytch validates Origin headers from SDK requests. When using Cypress, you'll either need to ensure that chromeWebSecurity: false, or if it must be true in the context of your tests, inject Origin headers into SDK requests.
cy.intercept(`https://test.stytch.com/sdk/**`, (req) => {
req.headers['origin'] = 'https://yourapp.net'
})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 Magic Link redirect routing 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&stytch_token_type=magic_links&token=TOKEN_VALUE. You'd extract the query parameters only: public_token=YOUR_PUBLIC_TOKEN&stytch_token_type=magic_links&token=TOKEN_VALUE.
2Add the query parameters to your own login URL
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&stytch_token_type=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 User with test email and password values.
- At the beginning of each test that requires a Stytch session token or JWT, call the Authenticate password endpoint with the test email and password values from the previous step. Be sure to specify the session_duration_minutes parameter so that a Stytch Session is started.
- 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 project keys from a Stytch test environment whenever possible. Our Test environments are built to support iteration and testing, and have different rate limits than our Live environment.
In cases where you do need to run tests using your Live project keys, you may need to create more than one test account that you can use during your testing flows in order to avoid hitting rate limits specific to an individual email address, phone number, or Stytch User.