Best practices for test data setup for a robust and concurrent test suite?

[penchef]

Hi y'all! 🤠

Goals:

1. a test suite, with tests independent of each other: tests are idempotent and can be run in random order, concurrently, or individually.
2. robust, repeatable, debug-able tests.
3. re-use the data seeding API in other test suites, i.e. in my mobile detox tests or even server-api tests.
4. relatively "fast" (= aka not unnecessary slow): I'm willing to trade a little bit of speed of an individual test for robustness and concurrency of the whole suite.

What are the best practices to setup your test data for (let's say ) a forum board app (user, login, discussion threads, etc...)*?

What I'm trying to do is to create the a distinct "sandbox" for each test, so that tests don't interfere with each other. By "sandbox" I mean a unique, e.g. user for the test + more relevant data (e.g. a new discussion thread + replies etc.). This would segregate each test's relevant data to a the unique user/thread and when a parallel test (or previous test) has created more threads/posts it doesn't matter to the current test.*

It's my understanding (and experience), that creating the setup data via UI interactions is not a good practice (slow, not relevant for the test, since user creation, login, and posting is tested in another test...), so my idea is to set up the data via API calls to my server.

My test would for example look like this:

before:

• new serverApi()
• serverApi.create new User Alice
• serverApi.create new User Bob
• serverApi.postNewThread Alice, "What are best practices for test data setup?")
• cy.login(bob) // set browser state to users bob
• cy.visit('/thread/what-are-best-practices-for-test-data-setup')

test "User can respond to an existing thread" :

• cy.click('response')
• ... // respond to thread and make assertions...

Problems/Questions

1. is this all a bad idea (I should not set up my test data through serve API calls) and there's a much better way to do this?
2. How do y'all set up your test data to achieve (at least some of) the goals up top?
3. CORS issues in the setup phase: when I'm using my own API-request client (i.e. axios; goal 3.) and not cy.request I have to fight CORS issues (CORS blocks the requests to my api server):
   ideally I'd like to write a serverApi library (with axios or whatever) which I can re-use not only for seeding test data for my web-app but also for my mobile client (plot twist!).
   I could write cy.commands (using cy.request which seem to bypass the CORS issues) to for all the data seeding, but then I'd have to do it all over again when I'm writing detox tests for the mobile app.
   I'm aware of disabling the SOP by default { "chromeWebSecurity": false, } but this is limited to Chrome and I'm wary to throw cross browser testing out of the window when I'm about to make a big time investment into a cypress test suite.

P.S.

I acknowledge that my CORS problem may not be applicable for most of y'all testing only one web-app, and that it is rooted in my goal #3 to re-use the test-data API client in multiple test suites.

With regards to the broader question of seeding the data: At a previous gig with a lot of teams and a complex Saas app, we had tremendous success to decouple teams/usecases and speeding up the test suite by seeding the data through a testApi and testing the web-app with Selenium. The testApi had all kinds of helpers (e.g. "get me a random user, with properties xyz, at a random company").
It enabled each test to be independent from the existing data of a test run, which is a must-have when you've got thousands of tests running in parallel. It also improved the debug-ability immensely, because a test was not dependent on a DB state and each test can be run quickly independently, without waiting for a length DB restore/reset, since it just creates all the data it needs.

Currently our server-api tests rely on a similar testApi, which interacts with the ORM directly (and is therefore not (easily) reusable in the cypress tests...

* in reality I'm testing a SaaS app with accounts + users + etc; accounts would serve as the segregating wall between each test

Edits: grammar + typos