facebook / screenshot-tests-for-android

Generate fast deterministic screenshots during Android instrumentation tests
http://facebook.github.io/screenshot-tests-for-android
Apache License 2.0
1.74k stars 229 forks source link

Can't record very large view inside ScrollView #310

Open mecoFarid opened 2 years ago

mecoFarid commented 2 years ago

Expected behaviour

We should be able to capture large views even if parts of it is outside bounds of the window. E.g. views inside ScrollView

Actual behaviour

Library captures only what is shown on the window and discards the rest of the view that is is outside the window

Steps to reproduce

Add multiple view(s) inside ScrollView until part of the ScrollVIew is placed outside the window then run the screenshot recorder task.

We can resolve the issue by providing viewHeight to setExactHeightPx() method but that is not an actual solution. Problem is you will get this issue Max Pixel Error if provided dimension passes the limits set by library.

I can't really find any proper workaround for this problem, this is a major problem given you test your device in different resolutions and wonder why almost no care is given for such a big blocker.

nispr commented 2 years ago

and wonder why almost no care is given for such a big blocker.

This part blows my mind. How about you do some care?

We work around this by capturing a screenshot per page of a ScrollView / RecyclerView (screenshot->scroll->repeat).

azabost commented 1 year ago

@nispr Hey. I'm facing a similar issue now and I'd be grateful for a few more details of your workaround if you can remember it. I'm wondering how exactly you scroll the ScrollView page by page between the screenshots. I tried scrollBy(0, scrollView.height), hoping that should do the trick, but I ended up with an unexpected behavior like this:

image

nispr commented 1 year ago

@azabost Hi Andrzej, please pardon my delay. Did you figure it out? We use scrollBy(0, it.measuredHeight). However I remember I had lots of main <> instr thread synchronization issues, basically resulting in screenshots being taken even though the UI was not completely idle. So after each screenshot, there's quite a bit of desperate manual sync (pushing an empty task to main thread, or the like). Perhaps this is your issue?

azabost commented 1 year ago

Hmm, I don't think my issue was related to threading, but I might be wrong.

Anyway, I dealt with my specific situation completely differently, e.g. I don't have a ScrollView anymore and I compare Bitmaps instead of screenshots of any views, which fits my needs even better than before.

I guess the short explanation above is too ambiguous and may leave you wondering what I was doing and why I don't need a ScrollView anymore, so let me say a few more words just to let you understand my situation (and why it was so specific).

I was working on a piece of machinery that was originally supposed to build some Views/ViewGroups (in memory, not even displaying them anywhere), then turn all of them into a Bitmap and print it on a physical printer (i.e. the Android UI system was used to create the content of the printout). At some point, I thought it would be great to cover the logic I created with some screenshot tests. Since I was creating Views anyway, I reused most of the logic in an artificial Fragment to display them, take the screenshot of said Fragment with Shot (Shot uses this repo as a dependency), and compare the outputs. However, I was building many views so they didn't fit on the screen, therefore I added a ScrollView and that's how I ended up with this issue. Later on. I figured out I can use Shot to compare the Bitmaps instead of Views/Fragments/etc., so I brought another piece of my logic for turning the Views into Bitmaps and I started comparing them instead. Now, I don't even need a Fragment to host the Views anymore, let alone a ScrollView.

I would still be interested to know how to resolve the problem I had, but it's not that important to me now.