On why writing Selenium tests is like writing raw js 5 years ago

I really thought js libs meant we didn't need to worry quite so much about cross browser quirks so much any more.

Writing some Selenium functional tests, it turns out that's not true.

I have a table. A simple table. With a header, footer, and body content.  With the html in the correct order, as it should be, thead then tfoot then tbody.

In my Selenium tests I generate a lot of tables.  I don't want to compare them cell by cell, so I'd taken the (what I thought to be) neat approach of grabbing the text the first time the test runs, saving it in a file, and then comparing subsequent runs with this known good.

Except.

It turns out that when running the test on Firefox, a call to $element->text() returns the text, without any html, as it appears on screen - that is, thead content, followed by tbody content, followed by tfoot content.

In Chrome, it returns the text, without any html, as the html is - that is, thead content, followed by tfoot, followed by tbody.

For the record, on IE it does the same as Firefox. (This all on a Win7 VM, IE10, Chrome/FF latest).


Which means the tests ALL FAIL when they shouldn't.


Which feels like trying to write cross-browser js all over again.  Painful.


UPDATE 28/4/14

I was wrong.  I jumped the gun.

The tables I was looking at are javascript generated, and inject a tfoot to hold some summary data.  It turns out that Chrome injects the tfoot between the thead and tbody, and so that's what it shows when you get the text content.  Firefox and IE append it to the markup, so it goes after the tbody.  So that's what shows up when you get the text content in FF/IE.

I've yet to look into why the html ends up different in the different browsers; it's possible that's where the bug is.

Anway, what I have learned: don't file bugs on a Friday afternoon.  Make sure your error report actually produces the error.