* Selenium has been on a multi-year quest to shift support for the browser drivers out to the browser vendors by way of the WebDriver W3C standard.
But I don't think anyone tracking Selenium development is going to be surprised by this move. It's been saved from absolute death a few times over by generous support of volunteers willing to pick it up. It's really been more of a zombie for years and just kept kicking along. * The death of Selenium IDE is anything but sudden. * When it comes to Selenium, Simon (the guy you replied to) is about as authoritative a voice as they come.
I understand where your concern is coming from, but I think you're missing a few of the pieces: (That said, I'm not against using something like Chrome DevTools to identify elements in the page, evaluate potential selectors, and so on. Recorders tend to have problems finding concrete things to wait for, especially for very dynamic pages. Specifying exactly what we expect to happen tends to be more robust (and faster) than either using static sleeps or some kind of implicit wait. Page Objects are an example of that: Īlso, writing the tests manually lets you use "explicit waits". In my experience, writing the tests manually for sufficiently "regular" applications ends up being more maitainable because you can put repeated logic in shared functions and classes, making it easier to adapt to changes in the GUI. > And while recorders present some challenges, manually coding UI-level tests make the maintainability issue an order of magnitude worse. I agree that is is important to structure the application to facilitate testing. I also know that other vendors are working on improving the spec compatibility of their implementations, so I think the future of WebDriver is very promising, with fewer differences between drivers that aren't the result of fundamental differences in the browsers under test. To expand further on Mozilla's ongoing commitment to WebDriver, we employ one of the editors of the WebDriver specification, are making significant contributions to the WebDriver testsuite, and are actively working on our geckodriver implementation to ensure that we have a fully-featured standards-complaint implementation as soon as possible. This is undoubtedly useful to some people, but as the original post says, there are alternatives in development that are targetting a similar niche, so the situation is not as dire as the title implies (I imagine the title is worded this way to reduce the number of duplicate bug reports that the Selenium owners have to wade through on the subject of Firefox 55+ compat. The only thing that will stop working is the Selenium IDE which is a XUL extension that allows writing selenium tests without writing any code. SauceLabs', and other testing-infrastructure-as-a-service providers' support for Firefox will be unchanged. This means that existing WebDriver-based browser automation remains compatible with with Firefox 55+. There seems to be a certain amount of confusion on this thread, so just to be sure that it's clear, Selenium itself will continue to work with future releases of Firefox.
0 kommentar(er)
