Creating tests for Android WebView usually means writing tests for “third party” code. Consequently you might need to struggle with not always suited for testing, unexpectedly changing code. Those who work with automation tests on a daily basis for sure know how problematic it can become to create and maintain such tests.

At Azimo, we allow people from around the world to transfer money via our app. We support various payment methods and some of them rely on displayed in WebView third party provided solutions. In order to fully test our application’s core feature, we have no other way but to provide reliable end-to-end tests.

First try

When dealing with WebView, first thing that will probably come to your mind is using Espresso-Web for your tests. That for sure will allow you to deal with simpler websites. But at the same time it requires you to analyse source code of the website in order to find hooks for Espresso methods.

We could give you some examples of inconveniences we came across during our work with WebView feature:

Security features preventing Espresso to access code of elements you would like to interact with. It could be for example part of the code hidden inside JavaScript block or inside iframe when code doesn’t allow you to use inWindow WebInteraction of Espresso.

WebInteraction of Espresso. Sometimes code is simply auto-generated and labels are different each time you access the web.

Unformatted spaghetti code of over 15000 lines.

WebView elements missing hooks which would allow Espresso to localise them within web code and perform action.

which would allow Espresso to localise them within web code and perform action. If you need to perform a lot of operations on WebView then matching when single action ends and the next one can start becomes troublesome and leads to flaky, unclean code.

Those are probably only a few of problems and we wouldn’t be surprised if you could name more of them. It is safe to state that there are cases which are impossible to handle only by relying on Espresso-Web. What to do when you hit the wall?

Different approach

Esspreso-Web strongly depends on loaded inside WebView source code. But what if you forgot about third party code entirely and focused only on Android?

Whole purpose of WebView is to allow you to display web pages as a part of activity layout. To be more precise, it will map elements of website which user can interact with into Android View objects and it’s extensions. You won’t be able to access those views with findViewById(int id) method as most of them don’t have ids or those ids are not accessible in your app package.

But those children are for sure present on the screen and you can track them by using Android Device Monitor:

Facebook login screen in WebView — view hierarchy

Those views can be accessed in tests with usage of provided by Google — UiAutomator.

To show how it could work, we will provide you example of code that allows to login to Azimo app via Facebook and it’s native WebView fragment: