Separate the layers: tests that state intent and assertions, page or component objects (or a domain-task layer) that know the UI, API clients and data factories for setup, and configuration and reporting. Selenium's own test-practices section encourages page objects, generating application state directly instead of through the UI, mocking external services, keeping tests independent, avoiding shared state, and using a fresh browser per test. Fowler adds that test code deserves the same care as production code, and recommends an arrange-act-assert structure. Start with one thin vertical slice (one login test running in CI) before building abstractions.

As the framework grows, those layers usually become separate modules: a core (configuration, environment resolution, browser or driver setup, logging), data (factories such as @faker-js/faker and seeders that give each worker its own state), application abstractions (component-based page objects and typed API clients), execution (the runner, parallelism and sharding) and reporting (JUnit XML, JSON and traces for CI). In an organization with many repositories, publish the core as a versioned private package (private npm or PyPI) that each application repository installs as a dev dependency, so feature teams write their own tests while execution standards stay in one place.

Sources: Selenium test practices, Fowler