In an end-to-end browser test suite, what do you gain and what do you lose by writing element lookups and steps inline in each test instead of extracting them into shared page objects or helpers?

## The two shapes An end-to-end test can be written **locator-first** — the test itself finds elements and drives them — or **abstracted**, delegating to a page object, a component helper, or a fixture. Both are legitimate. The interview question is not which is correct; it is whether you can name what each buys and what each costs, and describe when you move from one to the other. ## What inline buys you **Locality.** Everything the test does is on screen. A new team member reads one function and knows the scenario. There is no jumping between files to discover that `checkout.completeOrder()` also applies a coupon. **Direct failure attribution.** When a step fails, the failing line is the step. Nothing has to be reconstructed, and the stack does not pass through shared code used by dozens of other tests. **Freedom to differ.** The third test that needs a slightly different path just writes it, instead of adding a parameter to a shared method that forty other tests call. ## What inline costs you **Duplication of knowledge, not just code.** The real problem is not the repeated lines; it is that ten tests each independently *know* how to find the sign-in button. Renaming that button is a ten-file change, and the odds that all ten copies are truly identical shrink over time. **Drift.** Copy four gets a wait that copies one through three lack; copy seven uses a slightly different selector. The suite develops accidental variants of "log in" whose differences nobody chose. **Noise.** A twenty-line arrangement block buries the one line that is the point of the test. The scenario stops being readable as a story. ## The rule of thumb Write the first test inline. On the second or third occurrence of the same knowledge, extract — and extract at the level where the knowledge actually lives. Two things make an extraction pay: 1. **It has more than one caller.** A helper wrapping something used once is a layer with no benefit. 2. **It is named after user intent, not DOM mechanics.** `signIn(user)` earns its place; `clickSubmitButton()` does not — it renames one line and now the reader must check whether it does anything else. ## The wrapper anti-pattern The most common wasted abstraction is one method per field: ```ts // adds a layer, removes nothing async enterEmail(value: string) { await this.email.fill(value); } async enterPassword(value: string) { await this.password.fill(value); } async clickSubmit() { await this.submit.click(); } ``` The test that calls all three is exactly as long as the inline version, but now every reader must confirm those three methods do nothing surprising. Collapsing them into one intent-level `signIn(email, password)` is the version that actually shortens the test and hides a decision worth hiding. ## Extraction is not all-or-nothing The useful middle ground is to extract **element knowledge** while leaving the **sequence** in the test. A module that exports the locators for a screen, or a helper that returns a scoped container, removes the duplication that hurts while keeping the scenario visible: ```ts const cart = page.getByRole('region', { name: 'Cart' }); await cart.getByRole('button', { name: 'Checkout' }).click(); ``` Here the test still reads as a sequence of user steps, but the knowledge of how to find the cart region can live in one place if it is needed elsewhere. ## What interviewers listen for Candidates who answer "always use page objects" are reciting a rule. The stronger answer names the cost — indirection, methods that grow flags, failures reported from shared code — and gives a concrete trigger for extracting: repetition, plus a name that describes user intent. It also acknowledges that a small suite of a dozen tests may rationally stay inline, because the duplication has not yet cost anything.