• What are End to End Tests

Want to write Tests at Formbricks?

We highly recommend to run the existing Formbricks End to End Tests locally to understand our framework and architecture and then dive into writing your own tests and contributing to us!

1. Identify a series of events that a user would go through when interacting with Formbricks
2. See if it exists here on our repository or not
3. If it does not, voila! You can now write and contribute to our testing suite and make us stronger than before 😊
4. If it does, see if it misses something and can be improved, if not, keep hunting for more ;)

How to write Tests at Formbricks?

• We use Playwright as our E2E Testing Framework across our web-app.

Fast and reliable end-to-end testing for modern web apps | Playwright

• You’ll find our Playwright config here. This is the place where we define how we want Playwright to set the tests up, you will mostly not be making any changes to this file unless necessary.

• Now, go to the apps/web/playwright directory and you’ll find a numerous files that end with *.spec.ts. These are the end to end tests that we currently have in place.

• Create a new file with the functionality as the name followed by .spec.ts. For example:

  <aside> 💡 API Key Test (Example)

  For example, if you want to write an E2E test for API Keys, then the file can be named as: apiKeys.spec.ts

  </aside>

• Now get into the file and import the fundamental methods we use from playwright

import { expect, test } from "@playwright/test";

• Now start writing your first test using a test.describe(). A describe allows you to group a set of similar tests inside one. Ideally, for simpler tests, you’d only have one test.describe() inside a test file unless you need multiple abstractions.

  • For the apiKeys.spec.ts example we can have a test.describe("API Keys Create & Usage")

• Now start writing individual test() components with smaller individual functionalities. These should be small enough to know that if one of them fails, only by looking at the name, one could identify what component failed/changed.

  <aside> 💡 API Key Test (Example)

  For the apiKeys.spec.ts example, we can have

  • test("Visit API Keys Page")
  • test("Generate Development API Key")
  • test("Make protected API Request with correct API Key")
  • test("Make protected API Request with incorrect API Key")
  • test("Make Production API Request with Development API Key")
  • and so on! </aside>

• Now, as you might have observed, we’d need some constant data for creating a user, logging in through those credentials, etc! To make it easier to access such data, we have all our mock constants here. Add in the constants which you need here as an object inside the users/teams/surveys objects.

• And to make things easier and to follow DRY closely, we have certain helper methods for common functionalities such as Signup & Skipping Onboarding which you can access via here.