Kaspresso
Kaspresso copied to clipboard
KasperskyLab
Flake safety auto scroll fails when scroll view has a padding
I just tried out your sample code and when I edit the "samples/kaspresso-sample/src/main/res/layout/activity_main.xml" layout to have a big space at the beginning like this:
https://gist.github.com/BenedictP/86dc99308851010bc11a4ada98f3c3e6
The samples/kaspresso-sample/src/androidTest/kotlin/com/kaspersky/kaspressample/simple_tests/SimpleTest.kt will fail. I can see Kaspresso is scrolling down but not far enough. When I remove the padding from the scroll view it works as expected.
Hi @BenedictP! Could you share the device/emulator specifications you were using? Or does it fail with any emulator config? I'd gladly investigate this...
@BenedictP @matzuk Hi, good news! I have some update on this.
The problem happens with views that are in the middle of the scrollView, not at the top or at the bottom. AutoScrollProvider scrolls till 90% of the view. On the other hand It seems that the padding of the scrollView hinders the clicking if covering more than 10% of the view, making it not clickable.
That scrolling happens in the "NestedScrollToAction()" inside AutoScrollProviderImpl#scroll. If we create another Action, let's say "NestedScrollConsideringPaddingToAction()" that implements the solution proposed in this blog, it just works. It would additionally fix scrolling when having a Coordinator Layout with CollapsingToolbarLayout child (nobody reported that yet though).
The question is: How do we want to approach this? Changing the current scrolling could break current behaviour in some apps... I was thinking that maybe creating an additional Interceptor that executes the this special scrolling for as last resort? This interceptor should take action only if the Autoscroll does not work.
What are your thoughts @matzuk?
I would gladly help opening a PR with a bug fix and the corresponding tests :)
@sergio-sastre Great news! I think it makes sense to create a separate interceptor. On the other hand, how can we break current behavior? Can you describe such scenarios?
mmm... thinking once again...not sure about breaking the current scrolling since the approach to scroll is different... but that uncertainty is what worries me.
The current interceptor tries to focus the view by using a view.requestRectangleOnScreenview(Rect()).
On the other hand, the interceptor with the proposed implementation do actually perform scrollView.scrollTo() instead, what actually gives more control on scrolling.
This might also lead to scrolling more than necessary (especially on big screens like tablets), since it seems this is only needed on some special cases. This extra scrolling could lead to a bit longer test execution times. if you have several tests on that screen, better to save that time I believe. And we would also play safe by not removing the current autoscroll interceptor
Moreover, by separating it in another interceptor, we also allow Kaspresso users to remove this interceptor/autoScrollInterceptor if wished for whatever reason.
I'll try to complete this over the weekend
I just tried out your sample code and when I edit the "samples/kaspresso-sample/src/main/res/layout/activity_main.xml" layout to have a big space at the beginning like this:
https://gist.github.com/BenedictP/86dc99308851010bc11a4ada98f3c3e6
The samples/kaspresso-sample/src/androidTest/kotlin/com/kaspersky/kaspressample/simple_tests/SimpleTest.kt will fail. I can see Kaspresso is scrolling down but not far enough. When I remove the padding from the scroll view it works as expected.
Hi @BenedictP! If this is a blocker for you, I can confirm that autoscrolling in scrollable views with padding would work if you use UiScreen, which uses Kautomator under the hood, instead of KScreen. That is because of the way Kautomator scrolls.
@AzamatCherchesov This has also been merged and is part of 1.4.2 :) https://github.com/KasperskyLab/Kaspresso/pull/321
@sergio-sastre thank you! :) Added it in release info https://github.com/KasperskyLab/Kaspresso/releases/tag/v.1.4.2
