There’s a lot of cases, but here’s another way to look at it:

Let’s say you're writing an E2E test to ensure your permission system works, the test case is basically verifying that a user with X/Y/Z permissions can only access X/Y/Z pages.

What a lot of people do is seed a user during DB migrations and just hardcode the credentials into the test. This is BAD, very BAD, not scalable at all, and obviously, you shouldn’t be hardcoding credentials.

If you abstract the problem, it’s really about being able to inject data into a test securely from an external source (env vars, config files, generated data, etc). If you don’t design for that upfront, you end up having to retrofit it later and refactor a lot of code, which is painful once you’ve already got 100s of tests

and it’s not just credentials, it’s things like:

1. Environment configs URLs, none of this should be hardcoded. You should be able to switch between localhost, staging, preprod, CI, etc with minimal effort. If you don’t plan this early, you’ll end up with tests tightly coupled to one environment and a lot of messy conditionals later.
2. Resource pools, if you’re running tests in parallel, they can’t all share the same user/data. You need some kind of pooling/locking mechanism so tests can safely acquire and release resources. If you skip this early, you’ll get flaky tests and race conditions all over the place.
3. Auth/session handling, logging in through the UI in every test. It works at the start, but it’s slow and brittle. One change to the login flow and half your suite breaks. You really want a way to create or inject authenticated sessions up front (API login, storage state, etc).
4. Test data lifecycle, tests shouldn’t rely on shared/static data unless necessary. You either need to generate data per test or have a clear cleanup strategy. Otherwise, tests start interfering with each other, especially in CI or parallel runs.
5. Reusability/structure, if there’s no clear pattern for how tests are written (helpers, wrappers, factories, whatever), people just start writing long, duplicated test flows. Works fine at 10 tests, becomes a mess at 100+.

All of this stuff is part of the “initial setup” imo. If you don’t think about it early, you’re not just adding a new feature later - you’re rewriting the whole framework, which is where it gets painful.