Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox 55 and Selenium IDE

seleniumhq.wordpress.com

Post reply on HN
Print view View original

121–130 of 132 posts

Re: Firefox 55 and Selenium IDE

#121

Post by fulafel »

danidiaz wrote: post #19

Test recorders are an antipattern. They lure you with their "no programming required!" siren call, but the generated scripts invaribly end up as a fragile, poorly abstracted mess. GUI tests suites, especially those created with recorders, are prone to become unmaintainable beasts full of flaky tests. This old interview with Bret Pettichord makes good points about the use of recorders: https://youtu.be/s_CUPs6xAWw?t=5…

Sounds like app specific recorders could be more robust and resilient to changes.

Re: Firefox 55 and Selenium IDE

#122

Post by romaniv »

danidiaz wrote: post #19

Test recorders are an antipattern. They lure you with their "no programming required!" siren call, but the generated scripts invaribly end up as a fragile, poorly abstracted mess. GUI tests suites, especially those created with recorders, are prone to become unmaintainable beasts full of flaky tests. This old interview with Bret Pettichord makes good points about the use of recorders: https://youtu.be/s_CUPs6xAWw?t=5…

UI-level tests are the only kind that reliably test the full stack of your application. No amount of unis testing will catch a missing button or a wrong config setting.

And while recorders present some challenges, manually coding UI-level tests make the maintainability issue an order of magnitude worse.

The best way to make web UI tests stable is to involve engineers and make sure that the pages are structured in the way that make automation and validation easy. Usually the changes required for this are trivial. When they're not, it often points out something in the UI that doesn't make sense anyway, like having no confirmations for user actions.

And in any case, automated UI tests are still better than manual UI test, which is what a lot of people are stuck with.

Re: Firefox 55 and Selenium IDE

#123

Post by nirvdrum »

blubb-fish wrote: post #98
blubb-fish wrote: post #90

Earlier quoted context omitted.

sure - but this might very well indicate a trend.

who on earth is downvoting my comments and why? when the developers involved with Selenium suddenly decide to just drop a browser for one of their sub-projects then this might very well indicate a trend - even if it's just that firefox is less actively supported in future.

I understand where your concern is coming from, but I think you're missing a few of the pieces:

* When it comes to Selenium, Simon (the guy you replied to) is about as authoritative a voice as they come.

* The death of Selenium IDE is anything but sudden. It's really been more of a zombie for years and just kept kicking along. It's been saved from absolute death a few times over by generous support of volunteers willing to pick it up. But I don't think anyone tracking Selenium development is going to be surprised by this move.

* 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 [1]. The goal is for Selenium to be more of an interface to browser-specific implementations of the WebDriver specification more than anything else. Which is to say, Selenium dropping support for a particular browser shouldn't be too concerning because the major browser vendors will be maintaining their own driver implementation.

* Slightly related to the above point, but Selenium IDE is not and never has been maintained by Mozilla. The Firefox WebDriver implementation, however, is. And Mozilla is heavily involved in the editing and drafting of the WebDriver specification.

Hopefully that helps assuage your concerns.

[1] -- https://www.w3.org/TR/webdriver/

Re: Firefox 55 and Selenium IDE

#124

Post by slgt »

romaniv wrote: post #116
jgraham wrote: post #81

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. This means that existing WebDriver-based browser automation remains compatible with with Firefox 55+. SauceLabs', and other testing-infrastructure-as-a-service providers' support for Firefox will be unchanged. The only thing that will stop working i…

> there are alternatives in development that are targetting a similar niche Which tools are out there (open source and as easy to use as Selenium IDE)?

I am evaluating E2E Test Builder and Kantu Selenium IDE Light, both are Chrome extensions and open-source.

Re: Firefox 55 and Selenium IDE

#125

Post by rgrieselhuber »

danidiaz wrote: post #19

Test recorders are an antipattern. They lure you with their "no programming required!" siren call, but the generated scripts invaribly end up as a fragile, poorly abstracted mess. GUI tests suites, especially those created with recorders, are prone to become unmaintainable beasts full of flaky tests. This old interview with Bret Pettichord makes good points about the use of recorders: https://youtu.be/s_CUPs6xAWw?t=5…

I co-founded a company called Functionize (https://www.functionize.com/) and we found the same, but the problem is one of assumptions: should you be generating scripts in the first place?

What we ended up doing on our platform was discard the notion of generated scripts entirely. Everything becomes data, not source code. If you're willing to make the tradeoff to a cloud service vs. having the code (many businesses are), it's a great model. If you prefer having control over the code, it will drive you crazy.

Re: Firefox 55 and Selenium IDE

#126

Post by slgt »

masklinn wrote: post #60
Osmose wrote: post #4

I'd be curious to see what the usage stats on the IDE are; my company (Mozilla, ironically) uses Selenium a ton, but as far as I know we write all of our tests by hand instead of with the IDE since it allows you to use patterns like Page objects to make your tests more maintainable in the long run. Although the last time I used the IDE was years ago, so it may be more flexible than it used to be. Does anyone extensiv…

IDE is a good way to kickstart the tests, it allows non-technical people to create skeletons for tests which can then be touched up/prettified/refactored by devs.

This describes exactly my/our experience. Test recording can be a great time saver when used properly. Sure, a Java or Python guru can write a webdriver test in "seconds", but she usually does not want too. Plus the "seconds" often turn into hours of coding and debugging ;-)

Re: Firefox 55 and Selenium IDE

#127

Post by Animats »

quazeekotl wrote: post #120
moosingin3space wrote: post #114

Earlier quoted context omitted.

They won't delay it since they've already begun breaking the old XUL extensions API in order to make room for new improvements. This is getting quite tiresome at this point -- extension devs have had over a year to port. If the extension devs are targeting Chrome too, it's easier to use WebExt than XUL anyway, and if they haven't spent this time to engage with Mozilla about expanding the WebExt spec so their extensio…

I think thats pretty unfair when mozilla has been straight up refusing to implement webextension equivilents to XUL based functionality that a lot of addons depend on. Such as the fact there is no way to enumerate what sites have html5 local storage stuff stored, thus no way to control or clear it on a per site basis, and they are not interested in changing this, rendering an addon like what self destructing cookies…

There is that. For big-name extensions like UBlock Origin and Greasemonkey, there's a Mozilla bug which is used as a tracker for Firefox-side issues which need to be fixed. Lesser extensions don't get that kind of attention.

When I was porting my extension, my big worry was "is there going to be something I need to do that doesn't work?" But there were no show-stopper bugs.

Re: Firefox 55 and Selenium IDE

#128

Post by danidiaz »

romaniv wrote: post #122
danidiaz wrote: post #19

Test recorders are an antipattern. They lure you with their "no programming required!" siren call, but the generated scripts invaribly end up as a fragile, poorly abstracted mess. GUI tests suites, especially those created with recorders, are prone to become unmaintainable beasts full of flaky tests. This old interview with Bret Pettichord makes good points about the use of recorders: https://youtu.be/s_CUPs6xAWw?t=5…

UI-level tests are the only kind that reliably test the full stack of your application. No amount of unis testing will catch a missing button or a wrong config setting. And while recorders present some challenges, manually coding UI-level tests make the maintainability issue an order of magnitude worse. The best way to make web UI tests stable is to involve engineers and make sure that the pages are structured in the…

I agree that is is important to structure the application to facilitate testing. But I find this surprising:

> And while recorders present some challenges, manually coding UI-level tests make the maintainability issue an order of magnitude worse.

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. Page Objects are an example of that: https://github.com/SeleniumHQ/selenium/wiki/PageObjects

Also, writing the tests manually lets you use "explicit waits". http://elementalselenium.com/tips/47-waiting 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. Recorders tend to have problems finding concrete things to wait for, especially for very dynamic pages.

(That said, I'm not against using something like Chrome DevTools to identify elements in the page, evaluate potential selectors, and so on. That is indeed useful.)

Re: Firefox 55 and Selenium IDE

#129

Post by shimon_e »

ajb wrote: post #77
nevir wrote: post #43

Earlier quoted context omitted.

Their sites aren't very clear - what differentiates their open source version ( http://devexpress.github.io/testcafe/ ) from the paid ($500/dev/year) version? ( https://testcafe.devexpress.com/ )

There is a reply here apparently from a developer of testcafe, but it's 'dead'. It's a perfectly reasonable comment, so hopefully the mods can resurrect it - and check if the account is banned for no reason (that's the only comment it made, so I don't see why).

The developers are in Russia maybe it's an IP ban?

Re: Firefox 55 and Selenium IDE

#130

Post by lesbaker »

danidiaz wrote: post #19

Test recorders are an antipattern. They lure you with their "no programming required!" siren call, but the generated scripts invaribly end up as a fragile, poorly abstracted mess. GUI tests suites, especially those created with recorders, are prone to become unmaintainable beasts full of flaky tests. This old interview with Bret Pettichord makes good points about the use of recorders: https://youtu.be/s_CUPs6xAWw?t=5…

That's why I always used the selenium UI script as a starting point when I was doing web app QA. It was easier in my experience to take the generated output and eliminate unnecessary steps and clean up the selectors than to start from scratch.
Post reply on HN