In Selenium, what do Select's getOptions and getAllSelectedOptions return, and what does each call cost?

## The three read methods | Method | Returns | When nothing is selected | |---|---|---| | `getOptions()` | every `<option>` under the wrapped select | the full list, unchanged | | `getAllSelectedOptions()` | the subset whose selectedness is true | an empty list | | `getFirstSelectedOption()` | the first option whose selectedness is true | throws `NoSuchElementException` | All three start from the same place: `getOptions()` is exactly a search for `option` descendants of the wrapped `<select>`, and the other two are built on top of it. ## getOptions is a fresh find on every call `getOptions()` issues **one remote find command each time you call it** and returns an ordinary `java.util.List` of element references. Two properties follow: - The list is a **snapshot**, not a live collection. Options the page adds afterwards do not appear in a list you already hold; you have to call `getOptions()` again. - The search covers descendants, so options nested inside `<optgroup>` groups are included, in document order. The order matches the `index` property that `selectByIndex` compares against. On a parking-permit renewal form whose zone dropdown is filled from a lookup service, that means a list captured before the lookup finishes stays short forever, no matter how many zones eventually render. ## What getAllSelectedOptions costs `getAllSelectedOptions()` filters `getOptions()` by asking each option whether it is selected, and **each of those questions is its own remote command**. For a 200-entry zone list a single call is: 1. one find command, returning 200 element references; 2. 200 separate selectedness reads, one per option; 3. a filtered list assembled on the client from the 200 answers. `getFirstSelectedOption()` walks the same sequence but stops at the first option that answers yes, so it is much cheaper when the chosen zone is near the top of the list and no cheaper at all when it is the last entry. Neither method is a single round trip, and neither is cached: calling `getAllSelectedOptions()` twice does all of that work twice. ## Keeping the round trips down - Call `getOptions()` once and reuse the returned list rather than calling it again inside a loop over its own result — that is the shape that turns one find into hundreds. - On a single-selection permit-type dropdown, prefer `getFirstSelectedOption()`: it stops at the first hit, while `getAllSelectedOptions()` reads every option before it can return. - Read what you need from an option you already hold rather than re-finding it: `getText()` for the label the applicant sees, `getDomAttribute("value")` for the code the form posts. - If you only need the number of choices offered, `getOptions().size()` is a single find; there is no cheaper count. - Remember that the wrapper caches nothing between calls. Two consecutive `getAllSelectedOptions()` calls do the whole find-and-read sequence twice, so hold the result if you need it more than once in the same step. ## When getFirstSelectedOption throws It throws `NoSuchElementException` with the message "No options are selected" — it does **not** return null, so a null check will never fire and a `NullPointerException` is not the failure you should expect. - On a single-selection dropdown the throw is rare, because a browser keeps one option of an ordinary `<select>` selected; if it happens, look at whether you are really on the control you think you are. - On a `<select multiple>` it is the ordinary way to observe "the applicant has chosen nothing yet", and code that reads a multi-selection vehicle-class list has to expect it. - `getAllSelectedOptions()` is the non-throwing counterpart for that case: it returns an empty list and lets you decide what an empty selection means. ## What the returned elements are The list holds element references bound to the option nodes that existed when the find ran. They are ordinary `WebElement` handles, so everything you can ask an element you can ask an option — its text, its attributes, whether it is enabled. What they are not is a snapshot of the option's **data**: every property you read from one of them is another round trip to the browser, which is why a loop that reads three attributes from each of 200 options costs 600 commands and takes noticeably longer than the single find that produced the list. The distinction that catches people is between the list and the elements in it. The list itself is fixed at the moment of the find and will never grow. The elements in it are live handles onto the page, so what they report can change between two reads if the renewal form updates the zone list underneath you.