we must support it because of the way ``NodeElement::selectOption`` works. So if a driver does not support it, the testsuite already fails for them.
Because of this, I'm sure that all drivers support getting it when the ``value`` attribute is defined on the element (BrowserKitDriver also thanks to the logic inside the ``catch(InvalidArgumentException)`` below). For options without the ``value`` attribute, for which the HTML spec [defines](http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#attr-option-value) the value as being the text of the option, this depends on the driver. There was already a test in place for JS drivers (which is why BrowserKitDriver was not failing it previously), which passes on Selenium2 and Sahi and is skipped on Zombie and Selenium1 (which is very weird as the implementation of the code in both of them seem to support it, which will be revealed easily when running the testsuite again as the skipping of the test will not catch the renamed test without an update)