#selenium

then you can grab an element on the previous page, do whatever causes the navigation, then wait for "staleness of" the element you just got the reference to.

i don't know if python has a built-in expected condition for staleness of an element, but it's not that hard to gin one up.

div#container exists on page=1 I click next and wait for div#container, it already is there so the code continues

no, you're missing the point.

say `element` refers to an element located by `div#container`. you with me so far?

The error I get is: selenium.common.exceptions.StaleElementReferenceException: Message: stale element reference: element is not attached to the page document

stay with me, here zathras.

k

you have a reference to element `div#container` right?

then you click.

then you use webdriverwait to wait for the reference to be stale.

after that, you can look for `div#container` (again using webdriverwait), and guarantee that the new one you find is on the page *after* the navigation caused by the click.

it's two webdriverwaits back to back.

one to wait for staleness of, the next to wait for the presence of the element to return.

ok clear

this seems to have the complete solution/explanation http://www.obeythetestinggoat.com/how-to-get-se...

so webdriverio is one implementation and webdriverjs is the "official" implementation yet the founder of selenium at sauce labs is endorsing webdriverio, but webdriverjs has shitty promise syntax so. I'm not confused as to which one to pick at all

there's also others like nighwatch js and protractor and shittyJavascriptSeleniumDriver.js 1 2 3 4 5 etc.

humanbird: the founder of selenium does not work at Sauce anymore(if you mean Jason Huggins)?

and hasn't been seriously involved with selenium development in *years*.

zathras i kind of suspected that you had to wait for a new page to load

so... which driver do you choose?

don't forget nemo.js ... gotta love js developers. :)

humanbird: i'm not a fan of JS based drivers

Async is not a good way to write tests

you make your life super difficult

i also ported the expected conditions to python :)

is it so important to be "official" as to pick webdriverjs that you deal with .then(function(){}).then(function(){}).then for EVERY findElementBy?

errant_rider, webdriverio is synchronous

promises in the tests are pretty bad you must admit

humanbird: so what is your goal?

if you like WD.io use it

humanbird: i don't generally work in js, so i really don't have an opinion one way or the other.

you are welcome to choose whatever implementation works for you

the developer of WD.io is a great person

hi5 @juangj. Exactly

o/

findlement(By.id("someDivId")).then(function(theDivelement){return theDivElement.getText()}).thenreturn blah etc

i'll point out here that the developer of the IE driver is an awful person, a shitty developer, and can barely get his shoes tied in the morning, much less produce code that works.

in wdio it's basically .element("#someDivId").getText()

jimevans: rofl

u are talking about yourself jim?

mach6: #truestory

kek

so "officialness" is really just not important

not to you, apparently

age is a bitch.. all I will say

is there a level of wc3 conformity between webdriverjs and webdriverio?

humanbird: i would not refer to anyone else, nor their work, especially something they'd spent volunteer time creating that way.

so, yes, i'm talking about me.

i would expect they will both be w3c compliant in the long run, yes

in the long run we are all dead, but what can you do

is there anything that wdio and webdriverjs do that the other doesn't (aside from the async vs sync feature)

wd.io has some built in conformity with many of the common unit test frameworks like junit etc

have you read the manual for WD.io?

webdriverio the javascript binding doesn't work with junit

guess if i don't want chained/nested then(function(){}).then(function(){}).then(function(){}).then(function(){}).then(function(){}).then(function(){}) i'd just pick webdriverio

every single selector... by id. by name. you add a then. then then then then then

so perhaps if you dislike the JS bindings, you can use one of the many other bindings?

errant_rider: like... using the Java/c#/Python binding in a nodejs shop?

and having a git subrepository cuz we are special?

and developers never ever looking at the tests ever because "EW. python/java/c#"

i'm not sure what answers you are looking for here. pick the language that works best for your situation. in JS, there are a few choices of bindings. pick the one you like best.

seems pretty clear that i will just pick webdriverio because it is inherently superior.

to the other alternative

if you have suggestions for how to improve one, then suggest them

we all like to whine about design choices, but understand that different choices were made by different projects for different reasons

it's just not that productive to go around saying somebody's work is "shitty" -- you're free to have the opinion and act on it, but please try to offer your criticism in a constructive way

async offers absolutely no performance increases/features that any tester would care about (the user isn't opening 10 tabs at the same time and looking at content at all of them simultaneously)

btw, i didn't say webdriverjs was shitty. just that promise syntax over and over again is

it really is.

besides. the core nodejs developers have already abandoned the project

well, perhaps you can choose your phrasing more carefully in the future

there's like 1 left

most of nodejs is owned by ibm and joyent now

did they change the license?

still mit for now

for express at least

not that there aren't people making another 20 middle tier javascript frameworks due to IBM owning the big one

humanbird: i use WD.js (https://github.com/admc/wd)

i like the whole syntax where you can thisIsAFunctionCall(browser.element("#something").getText)

no more chaining etc

even better, pass a function reference that returns a value

I agree that its easier to use a non-async choice, but I don't think its too bad after you get used to it. I would prefer a different language binding if it was my choice tho (java). I would even prefer a different JS binding too (webdriver.io for its active community)... but the choice isn't mine.

using '.' as a line separator is worse than using the optional ';'

i just don't want to do it kek

anyways they are giving me some freedom here (within the confounds of nodejs) to pick whatever tools

sauce/browserstack/linux/windows/osx/whatever driver etc

confines