Which ferry-booking assertions break on a remote browser whose window size, locale and clock you did not choose?

## The machine had opinions before you arrived A browser on a rented fleet is not a blank slate. It runs on a host with a screen resolution, in a window of some size, with a system language, installed fonts, and a clock set to some time zone. Every one of those was decided by whoever operates the machine. Your own laptop has the same settings, but you chose them, you can see them, and they have not moved for months - which is exactly why a test comes to depend on one without anybody noticing. The failures this produces share an unpleasant property: **they look like product defects**. A booking page showing the wrong departure time, a "Confirm crossing" button that cannot be clicked, a total with the wrong decimal separator - each presents as the application misbehaving, and the first hour of investigation goes there. ## What breaks, and why - **Layout and visibility.** A narrower viewport moves controls below the fold, collapses a table into a stacked list, or hides navigation behind a menu. A click that worked at your own window size fails, and the error says the element was not interactable rather than that the window was small. - **Formatted dates and times.** Day-month-year against month-day-year, a clock with morning and afternoon markers against one without, the name of a month in another language. An assertion on a rendered departure time is an assertion about the locale as much as about the crossing. - **Numbers and currency.** Decimal and thousands separators swap by locale, as do currency symbol placement and spacing. - **Date boundaries.** A crossing departing late in the evening falls on different dates in different time zones, so a case built around "today" can pass in one place and fail in another for reasons unrelated to the booking logic. - **Text metrics and fonts.** A different font set changes measured widths, hence wrapping, hence what is visible and where. ## The open implementations show the shape These are settings, not mysteries, and open grids name them - the clearest way to see that somebody always chooses them. - **Selenoid**, unmaintained by its own README, offers a `screenResolution` capability and states in the same documentation that it sets the container's screen resolution and **not** the browser window size, that its containers run headless without a window manager, and therefore that `maximize` does not work and you must set the size explicitly. - **Selenoid**, still unmaintained by its own README, also offers a `timeZone` capability, and its documentation says that without it browser containers simply inherit the time zone of the Selenoid host - a default nobody chose for your test. - **Selenoid**, unmaintained by its own README, also exposes per-session environment variables through an `env` capability, whose documented example is precisely testing with different default locales. On a closed provider you cannot inspect the equivalent, and you may not be offered every knob. That is the real difference: not that the phenomenon is impossible elsewhere, but that the value was set by someone else and stays invisible unless you ask the session what it has. ## What to do about it 1. **Set the window size explicitly at session start.** Choose the size the case needs and set it rather than maximising and hoping; this removes the largest and cheapest difference between two machines. 2. **Assert on the data when the data is the subject.** If the case is about which crossing was booked, assert on the underlying value or a stable identifier, not on the string the page rendered. 3. **When formatting is the subject, state the expectation.** Declare the locale and time zone the case requires, and fail loudly with a clear message when the browser reports something else - a failure that says "this session reported a different locale" is worth far more than one that says a string did not match. 4. **Never build a date case on the machine's wall clock.** Inject the date the scenario needs, so a late-evening crossing tests the boundary you meant rather than the boundary the host happens to be in. 5. **Read the environment back and log it.** Window size, reported locale, reported time-zone offset, and the browser build the session reports, captured at session start and attached to every result. That last point turns a recurring mystery into a quick diagnosis: instead of guessing what the session had, you read it from the log, and a failing case can usually be reproduced locally by applying the same settings. | assertion style | survives a foreign environment | notes | |---|---|---| | on an underlying value or identifier | usually | the safest default when formatting is not the subject | | on a rendered, formatted string | only with locale and time zone stated | otherwise it tests the machine as much as the product | | on element visibility or position | only with the window size set explicitly | maximising is not a substitute for setting a size | Pinning seeds, locale and encoding as a general discipline across a whole test estate is its own subject. The narrower point here is diagnostic: on a machine you did not configure, those settings are both a live failure source and the first thing to read back, because until you know what the session had, every explanation is a guess.