Hi,
We are using Geb, associated to a ChromeDriver instance to execute a bunch
of browser tests on our application.
Some of those tests are flaky, mainly due to the lack of 'waitFor {}' calls
around animations that happen when clicking a web element.
In order to help us understanding and fixing the flakiness, we capture
screenshots when a test fails.
But this is sometimes not enough.
Say, the test fail with 'waitFor { someElement.displayed }', the screenshot
will either show
- that the element is indeed not displayed
- that the element is displayed, but that doesn't help. It might be that by
the time the screenshot is captured, the animation is actually finished and
the screenshot doesn't really reflect the _exact_ state when the failure
occurred.
So, in order to assist even more, I had the idea to enhance the screenshots
with some data.
Basically, I added a 'ReportingListener', that grabs the created PNG
screenshot, and writes a bunch of stuff on top if it, using java's
Graphics2D API.
Currently, I add info like:
- the browser dimension (it can help in case of tooltips being displayed
and hiding elements between them. These tooltips positions can differ based
on the browser's dimension)
- the browser URL
- the current 'document.activeElement'
- the current cursor position.
- since we can't get the mouse position directly, but only when the mouse
moves (correct me if I'm wrong), I hack around this by adding a
'document.onmousemove
= event => { window.mouseX = event.pageX; window.mouseY = event.pageY'
script, and then do 'browser.interact { moveByOffset(1, 0) }', and then
execute 'return [window.mouseX, window.mouseY]', and substract 1 to the
mouseX returned value.
- I also capture the cursor position before and after click
- I added a NavigatorEventListener
- implement 'beforeClick' / 'afterClick' and use the same approach as
above to store the Navigator.x / Navigator.y values in some variables to be
picked up by the 'ReportingListener'
- This helps a lot in case where clicking an element triggers an
animation that moves the element being clicked.
See for instance this page
<https://scans.gradle.com/s/qxtasxn3dikjc/timeline>, and click the
magnifying glass.
In theory, if our 'waitFor { }' were perfect, the 'afterClick' cursor
location should still be on the magnifying glass (that has moved vertically
after the 'slide down' transition). But the screenshots now show that this
is not the case, bringing an actual proof that the waits are not properly
working. They just don't properly wait for the end of the animation.
This can be seen in the two attached screenshots :
- the cursor is correctly on the top-left corner of the magnifying glass on
the 'beforeClick' image
- in the 'afterClick' one, the cursor has slightly moved vertically,
following the slide down transition, but it actually is not on the top-left
corner of the magnifying glass
Does this sound like a sensible approach to you?
Would it make sense that I work on making a PR to integrate that in some
sort of ways in Geb?
--
You received this message because you are subscribed to the Google Groups "Geb
User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to geb-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/geb-user/8ba05fdc-cd86-4d3e-a0ba-f2ca80252da2%40googlegroups.com.
