splinter icon indicating copy to clipboard operation
splinter copied to clipboard

deprecate all finders but find_by_css and find_by_xpath

Open fabiomcosta opened this issue 12 years ago • 12 comments

In order to make splinter simpler to use by decreasing the number of methods on the public API, we should deprecate all the find_by_* methods but find_by_css and find_by_xpath.

Thoughts?

fabiomcosta avatar Aug 23 '12 02:08 fabiomcosta

+1

douglasmiranda avatar Aug 23 '12 05:08 douglasmiranda

-1

1- I think find_by_* ir more readable 2- There's probably a lot of people who doesn't know xpath or css selector (yes, they should learn it), but like myself, when I started using splinter I didn't know how to select elements with css or xpath. With this methods I think it makes splinter easier for people with less knowledge. 3- Read 1

bernardobarreto avatar Aug 23 '12 22:08 bernardobarreto

@bernardofire we have 2 ways of doing the same thing right now. Every web developer should be familiar with CSS, it's definitely not a barrier.

fabiomcosta avatar Aug 23 '12 22:08 fabiomcosta

I've been thinking...

Would be very difficult to implement a method named find()? Once the syntax of xpath and css selectors are little bit different, I think we'll be able to detect if the argument will be a xpath or css selector (regex or something like this).

browser.find('#foo .bar a')
browser.find('/table/tbody/tr[3]')

Maybe is not be the best way, because the find_by_SOMETHING() is more explicit, but just saying this is a suggestion.

douglasmiranda avatar Aug 24 '12 17:08 douglasmiranda

We could have a find that uses css, since it is the "default" for html documents and a separate find_by_xpath. The problem with xpath is that it's meant to be used on an XML document, and a HTML document is not necessarily an XML document. We can keep it, but as something "optional", not the official way of selecting elements.

fabiomcosta avatar Aug 24 '12 17:08 fabiomcosta

Yes, agree.

If we use find() like in javascript/jquery, ($.find('a')), it will be more understandable for front-end developers, I think.

douglasmiranda avatar Aug 24 '12 17:08 douglasmiranda

I'm +1 for drop find_by[id, tag, name].

But I'm -1 for a generic find.

andrewsmedina avatar Aug 25 '12 19:08 andrewsmedina

+1 too, and -1 to a generic find: better to be explicit ;)

There would be space to refactor the is_element_present_by_something too?

michelts avatar Dec 03 '12 15:12 michelts

@michelts yes. find, is_element only by css or xpath :)

andrewsmedina avatar Dec 03 '12 16:12 andrewsmedina

:shit:

bernardobarreto avatar Dec 03 '12 16:12 bernardobarreto

Why would you include xpath?

Don't use xpath in automated browser testing.

I use css for everything, unless I have an id. I vote find_by_css and find_by_id, and that's it.

Droogans avatar Jul 19 '13 22:07 Droogans

Hi @Droogans,

with find_by_css and find_by_xpath you can find everything. A best practice is to use css, because the css selector makes the test more readable.

But splinter is not only used for interface tests, it is used too for crawlers, bots and other things. In some cases xpath selectors can be easier and more readable than css selector.

andrewsmedina avatar Jul 19 '13 23:07 andrewsmedina

Closing this issue due to #933.

The find_by_ methods will remain and a find() method has been added.

jsfehler avatar Feb 13 '24 17:02 jsfehler