A suite I inherited passed every night for a year, then started failing twice a week. Nobody had changed the tests.
Two different tests both created a contact called "Test User". For a year they happened to run in an order where it did not matter. Then the suite got faster, they started running closer together, and one test began finding the other's leftover data.
That is a test data bug, and it is one of the most common causes of a suite that "randomly" breaks.
Static data is fixed and written into the test. The name "Dana Fox", the price 19.99, the login demo@nimbus.app. Predictable and easy to read.
Dynamic data is generated when the test runs. A name with a timestamp in it, a random email address.
Neither is correct everywhere. The choice depends on one question: does this test create data, or only read it?
Tests that read shared data should use static values. If your app has a seeded catalogue of products, testing that the search finds "Terra Mug" is fine. Nobody is changing it.
Tests that create data should generate their own. This is the rule that prevents the story above:
const name = `Dana Fox ${Date.now()}`;
Now every run creates a name nothing else uses. Two tests running at the same time cannot collide, and yesterday's leftovers cannot be mistaken for today's row.
Three more habits that matter as much as the choice itself.
Every test should create what it needs. If test B only passes because test A created a contact first, you do not have two tests. You have one long test split across two files, and running them in a different order breaks both. This is called an order dependency, and it is the single most common reason a suite passes locally and fails on a build server, where tests often run in parallel or in a different order.
Clean up, or design so you do not need to. Deleting your data at the end is polite, but cleanup code does not run when a test crashes. Unique data is more reliable than careful cleanup, because it keeps working when things go wrong.
Never assume an empty starting state. A test that asserts "the list has 1 row" after creating one contact will fail the moment anyone else leaves a row behind. Assert on your row, not on the total, unless you fully control the data.
Remember this: if two tests can touch the same record, they will, on the worst possible day.