Hmm, in my experience, the problem with switching iframes is that it can get quite complex when your page has multiple nested frames. You are only able to switch to an iframe that is a child of the currently selected iframe (or the default content if the element is not in an iframe). If you don’t get the switching sequence exactly right you’ll get NoSuchFrameException. Conversely, if you try to refer to an element and you haven’t switched to the right iframe beforehand, you’ll get NoSuchElementException. All of this puts a lot of burden on the writer of the test, who in the latter case might think that they need to wait longer for the element to appear when in fact they are just in the wrong iframe! It’s quite possible that in a test you might want to refer to a web element that is buried deep in a nested iframe, followed by a reference to one that’s not in an inframe at all. If you leave responsibility for this to the writer of the test, they would need to keep track of which iframe they were last on, in order to know whether a switch to default content is first required before they then switch to the child iframe. All this can get extremely messy, fast and clutters our beautiful test!. Another problem is that a Task might work fine at one point in a test but might fail later on because another Task switched to a different Iframe beforehand.
Given that the relationship between a web element and its iframe(s) never changes, to me it makes sense to define this relationship up-front within the Target, just like you would do with the locator.
In the java Serenity core library, an IFrame is an Optional type on the Target, so by default, a Target will exist in default content. An IFrame is constructed with a vararg of By locators which allows any nesting depth to be modelled. Switching of the IFrame is done transparently by means of the iFrameswitcher which is invoked within the TargetResolver. I relied heavily on the transparent Iframe switching capability when I worked with one particular client for a couple of years and I was very glad this feature was in serenity-core!
Given this background of how the problem was tackled in the java product, do you think this is something that could be of value in serenity-js?
The text was updated successfully, but these errors were encountered: