QA

[ijreilly]

Main things to test

• Sign-in
• Sign up (create a new workspace)
• Run sync-metadata on all workspaces at least two times:npx nx run twenty-server:command workspace:sync-metadata -f
• Reset the database (yarn nx database:reset twenty-server ) then connect to the workspace
• Seed your environment with demo data - we seed demo environment with data everyday so we should check this still works (npx nx workspace:seed:demo), then connect to the workspace

[BOHEUS]

As I'm working on it right now, I'd like to bring up few important things which are necessary in my opinion:

• the modularity of automated tests (reusability of tests, ease of adding and changing as well as fixing modules when new features will be added)
• writing logs of tests (probably with each executed step on top of starting and ending test with result) - Playwright offers few different ways of writing logs (https://playwright.dev/docs/api/class-testconfig#test-config-reporter), I think HTML for running tests on my own device and Github for CI/CD pipeline will be a good choice but it's always possible to override this using custom reporter
• screenshots of tests (easier for debugging tests and possible reporting bugs)
• adding tests to pipelines (sooner the better)
• packages of tests per main view (companies, people, tasks, notes and such, I'm open to discussion)
• drivers to OS terminal (to run commands such as yarn) and database (if some features are hidden behind some custom configuration and can't be set from the UI but that may become problematic to maintain if other databases will be added and the driver won't use ORM)

Automated tests should also be as much versatile as possible so they can be used in day to day testing as well as regression tests.

I'll investigate the subject further and try to create the foundation of QA but I have few questions:

• how someone can know which bugs are subject to creating automated test? Will they be added to different dashboard, reported issues after fixing will get special label informing it should be automated or something else?
• is roadmap a good way to understanding the business logic and writing the tests for it?
• will core team perform code reviews in pull requests as it does now or someone else will be responsible for it?
• will core team provide the access to account for only testing purposes on Google Workspace (such as testing mails and oauth integration) if it has active workspace? If so, how will it be secured and who will have access to it?

[charlesBochet]

Hi @BOHEUS, thanks for taking the lead on that!
Could you write a first test on the sign in? It will be a good base to discuss the points you mentioned and integrate it to the CI

Regarding your questions:

• E2E tests are costfull to run and to maintain, I believe we should only tests critical paths (we have many though!): sign-in, sign-up, object creation, ... Most bugs won't lead to E2E tests but rather ton integration tests on the API, unit tests or stories on the FE. Regarding big regressions that could lead to an E2E tests, we can create github issues when we think it makes sense
• It's partial but we can use https://twenty.com/user-guide/ as a support
• Yes the core team will keep doing the code review, it's not unusual that some contributors are trusted to make most of the review but the merge will be triggered by someone from the core team for security reasons :)
• good one: we would likely not include SSO / mail sync in the E2E for now. We can cover this part with integration tests for now and right E2E tests on a pre-filled database for the read part

[BOHEUS]

Hi @charlesBochet, in my fork there's special branch for QA tests, you should check it out.
Like I wrote earlier, I'm trying to structure everything in modules and make it easier to work with but the tests listed out by @ijreilly are already done, some fixes with commands are needed though as all tests except the last one work.

I'll publish any changes there before merging and such.