Check the option value and its label.

A select control shows Weekly, while its option value is weekly_demo. The test selects Weekly and reports the value as though it were the same string. The interface looks plausible, but the report has lost the distinction between what a person reads and what the control holds. Both may matter to the requirement.

Playwright's Actions guide supports selecting options by value or label. The Locator API says a string can match either, while an object can name the field explicitly. Use that explicit form when the distinction affects the case, then assert the relevant selected state.

Name the field used for selection

Our invented native select has a Delivery cadence label and two options with different labels and values. No order, subscription or delivery is created. The demonstration selects the weekly value and checks its visible option text separately.

const cadence = page.getByLabel('Delivery cadence');
await cadence.selectOption({ value: 'weekly_demo' });
await expect(cadence).toHaveValue('weekly_demo');
await expect(cadence.locator('option:checked')).toHaveText('Weekly');

This snippet needs the Playwright runner and imported expect. It targets a native select, not a custom popup that only looks like one. The option:checked query inspects the selected option inside that control. For this single-selection fixture, exactly one selected option is expected.

A second local case selects by the label Monthly and verifies the returned value monthly_demo. It records input and change events for the local control. These observations confirm the API's mechanism in this fixture, not how every application commits a selection to a server.

Check what a renamed label changes

If a label changes during localization, its stored value may stay stable. A value-based selection can still work while the user-facing label is wrong. Keep a label assertion when visible wording belongs to the requirement. Conversely, selecting only by label does not prove the stored value is the expected identifier.

Use an agreed test value rather than an incidental option index when identity matters. Index selection depends on ordering. If the requirement concerns the first recommended option, check that ordering and identity explicitly instead of treating an index as a stable business identifier.

The documentation says selectOption waits for the requested options to be present and triggers input and change after selection. That does not establish whether the application accepted the change. Check the resulting interface state and any required authorized server evidence. Avoid adding a blind delay after selection as a substitute for that evidence.

Keep control type and cardinality in the case

A custom combobox may require a different interaction from a native select. Inspect its implementation and accessible behavior before copying this API into a generated test. A similar visual shape does not prove the same control contract.

Multiple selection also changes the expected result. Use the appropriate list of option values and assertions for that control, rather than extending this single-option text check without review. Our specimen deliberately stays with one selected option so the evidence is easy to inspect.

When reviewing tests prepared by an agent, record control type, matching field, expected value, visible label and any persistence requirement. AnyTest describes exploration and tests for human review; no particular select-control implementation is claimed. Keep the selected identifier and the reader's label distinct in the report.

If a value and a label coincide today, keep the chosen matching field explicit anyway when the contract requires it. This makes a future rename easier to review and avoids quietly changing what the test uses as the option identity.