LogoLogo
  • 👋Cal.com Handbook
  • The Company
    • ❓What is Cal.com?
    • 📈Mission, Vision and Values
    • 🅰️Glossary
    • 📈Organization Chart
  • HR & Careers
    • 👷Contract-to-hire trials
    • 🛫Onboarding
    • 🏆IC Levels
      • ⛰️Engineering Levels
        • 🕵️IC1 Engineer (Code Cadet)
        • 👷‍♀️IC2 Engineer (Code Craftsperson)
        • 🧘‍♀️IC3 Engineer (Code Connoisseur)
        • 🧙‍♂️IC4 Engineer (Code Wizard)
    • 💡Sharing your views
    • 💸Bonus & Equity Structure
  • Policies
    • 🏖️Vacations
    • 💳Expenses
    • 🗣️Communications
  • Engineering
    • 🔔Managing Notifications
    • ⭐Valuable Bookmarks
    • 🐛How to report issues
    • 💻How we work on Tickets
    • 🔥What to do during Emergencies
    • ✅PR Reviews
    • ☑️Self-reviews
    • 📚Keeping Docs up-to-date
    • 🌐HTTPS & Subdomains
    • 🎯Best practices
      • Data fetching
      • Avoid Prop Drilling
      • Prefer defaultHandler for simple API handlers
      • Prefer inferred types over explicit ones
      • Prefer early returns
      • Avoid comparing multiple values with `includes`
      • Validate using zod instead of type casting
      • Prefer Composition over Prop Drilling
      • Prefer ternaries over Short Circuiting “&&” for React Components
      • Don't modularize prematurely
      • Only select data you need
      • Disallowing the use of unrestricted Metadata fields
      • E2E Tests Best Practices
    • 💻Codebase
      • 🔓Keeping the lock file in sync
      • 🚫Git Private Submodules
      • 🏎️Monorepo / Turborepo
      • 🌝Deploying to Production
      • ☁️Deployment
      • 💻Debug Desktop App
      • 🚩Enabling/Disabling Features
    • 🔺Resolving failed migration on Vercel Preview
    • 🔦Cal.com Status Page
  • Customer Success
    • 💟Tone
  • Marketing
    • 🎬Media
    • ☝️How to add a new Tip to Sidebar
  • 🤲Sales
    • Operations Stack
Powered by GitBook
On this page

Was this helpful?

  1. Engineering
  2. Best practices

E2E Tests Best Practices

These are some basic principles that should be respected when working with E2E tests. Failure to follow these practices can be a motive for PR rejection.

PreviousDisallowing the use of unrestricted Metadata fieldsNextCodebase

Last updated 1 year ago

Was this helpful?

  • A test should avoid using Text Locators: page.locator('text=

    • Add a proper to data-testid to the HTML element and retrieve it by using page.getByTestId

    • From :

      • Testing by test ids is the most resilient way of testing as even if your text or role of the attribute changes the test will still pass. QA's and developers should define explicit test ids and query them with page.getByTestId(). However testing by test ids is not user facing. If the role or text value is important to you then consider using user facing locators such as role and text locators.

  • A test should be able to run locally as well as on CI

  • A test should be able to be run multiple times and expect a consistent result

  • A test should not introduce side-effects that may affect other tests running in parallel

  • A test should use expect(page).toHaveURL() so we can fail fast if a new unexpected redirection is introduced

  • A test should avoid using fixed seeded records for testing.

    • This conflicts with parallelization and consistency

  • A test should reset the DB state to be the same after running tests than it was before running them.

    • This means all created records should be properly cleaned up after tests are run

    • If seeded records were used, return them to their original state afterwards.

TODO

  • Guide for debugging E2E failures

    • What to do when checks fail?

    • How can I know where to look?

  • Recommended Tools and extensions

  • Workflow recommendations for working with E2E tests

🎯
Playwright docs