E2E testing should be able to query the DB to work on actual data and not hard coded mocks.

[lucasbordeau]

Scope & Context

E2E testing

Expected behavior

We want our e2e testing package to be able to launch graphQL Queries against the URL set in its .env.

That way we can for example test that when we login we see the first names that are in the DB for Companies.

And other tests that would require to know what's in the DB to make the relevant assertions.

For now we can set the authorization token in an env var.

[BOHEUS]

I'm working on it, please assign me to it

[shwetd19]

Hey @lucasbordeau

To address this, We can update the e2e testing configuration to include the GraphQL endpoint in the .env file. Then we can modify the test setup to fetch the endpoint URL from the .env file and implement queries against it. This will allow us to test various cases, such as verifying the display of user data after login. Ensuring that authorization tokens and other necessary configurations are correctly applied during tests to reflect real-world conditions.

Can I work on this ?

[lucasbordeau]

@shwetd19 Can you please discuss this with @BOHEUS as he's taking the lead on E2E testing ?

[BOHEUS]

In #6644 I modified the .env.example file to contain GraphQL URL (as well as REST API URL), for now it's commented and directing to local instance but it can easily changed to any other URL like Demo instance. The bigger problem is with storing the token as it's generated per workspace (so it's unique) and can't be mocked (or I don't know any way how to mock it properly). The solution for this would be probably using the global setup which runs before any tests with API (or maybe even before all tests? To be decided) and stores the token in the process.ENV

Reference: https://playwright.dev/docs/test-global-setup-teardown#teardown

I'll take care of that as it's not really hard to do.

[BOHEUS]

@shwetd19 if you want, you can create all necessary GraphQL queries, it'll help a lot, just be aware how it's done as it's different compared to normal Web tests, I'm sending some documentation which I hope will help you understand.

FYI, queries must be mashed into one line in order to send them to API (check the blog post in second link).

Documentation:

• https://playwright.dev/docs/api-testing
• https://www.jayfreestone.com/writing/stubbing-graphql-playwright/

[lucasbordeau]

@BOHEUS Could we implement msw ? Like in stories ?

[BOHEUS]

@lucasbordeau could you explain what does "msw" stand for? I'm not sure about the meaning behind this abbreviation

[lucasbordeau]

Sure ! We use https://mswjs.io/ for mocking our GraphQL API in stories, this way we don't have to bother with mocking anything in the frontend code, we just mock the response for a specific request.

We use msw-storybook-addon, maybe there's one also for our use case.

Also it would help to think about how we could re-use what we already wrote for stories in a shared folder of msw mocks.