test: seeding a pool of test users for e2e tests

[codeincontext]

Problem

At the moment, all our e2e tests use a single test@thenational.academy user. This is limiting us because:

• That account isn't a demo user, so we can't test demo functionality
• The account is reused between tests, so we can't test rate limits, user bans, other stateful behaviour
• The single clerk account has different database state on each dev's machine

Description

• test-support tRPC router and prepareUser mutation
  • Prepares a test user for the upcoming test
    • Uses an email address pattern to reuse a pool of accounts
      • Test users are unique by variant. A variant will set up the account in a certain state
      • Test users are unique by environment. An environment can be a vercel preview branch or a local machine hostname
      • eg: test+my-branch-demo@thenational.academy, test+matts-macbook-demo@thenational.academy
    • Resets and returns the matching clerk user. Or creates it if missing
    • Returns a single use sign-in token
• test-support nextjs page
  • Creates a clerk session with a sign-in token
• demo e2e test
  • An example of using the new system to test an account in the demo state

Not included at the moment:

• Preparing users and caching their cookies in a setup step, like our current auth pattern. This would save us a few seconds for each test but adds complexity we don't need yet

Issue(s)

Fixes #AI-553

How to test

1. run pnpm run test-e2e-ui
2. Navigate to demo-accounts.test.ts and the test inside
3. Press play
4. Check clerk to see the new user created

Screenshots

First run:

Second run:

Checklist

• Manually tested across browsers / devices
• Considered impact on accessibility
• Does this PR update a package with a breaking change

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
oak-ai-lesson-assistant	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 25, 2024 0:32am

[mantagen]

Great idea here. Will we need to think about some kind of clean up if we're creating ephemeral users, say, per-branch?

[codeincontext]

Great idea here. Will we need to think about some kind of clean up if we're creating ephemeral users, say, per-branch?

So the impact should be:

• X users created per branch pushed. Where X is currently 1, but I could see it being something like 8
• X users created per dev machine (that seems fine to me)

We do already create a small number of ephemeral users when testing and it hasn't caused any issues yet. If it starts to become a problem, we could look at a script to clean up test accounts which haven't logged in in X days, or a github workflow to clean up when a PR is closed

Update: There's a bit of a judgement involved as well, because it's not necessarily a negative to have a staging environment that's more full if it brings it closer to production. That's a bit of a can of worms though!

[github-actions]

Playwright e2e tests

Job summary

Download report

To view traces locally, unzip the report and run:

npx playwright show-report ~/Downloads/playwright-report

[sonarcloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[stefl]

Looks very helpful!

[stefl]

Maybe just "lessons per month" if that is going to change?

[codeincontext]

That's an interesting point. Ideally it should be reset when the user is prepared so this is actually quite a useful test!