Finish documentation of SharedTests and AndroidTests in ::app module

[fknives]

No description provided.

[fknives]

Don't forget to mention the issue with ProgressBars with Espresso: namely that progressbar and other infinite loading indicators will make the MainThread not Idle, thus Espresso actions lock up,
Reference:
https://stackoverflow.com/questions/30469240/java-lang-runtimeexception-could-not-launch-intent-for-ui-with-indeterminate
https://stackoverflow.com/questions/35186902/testing-progress-bar-on-android-with-espresso

All original links provided in reference are outdated sadly

[fknives]

Additional notes to add to SharedTests:

• dialogs are not handled the same way by Robolectric. Can't test them with Espresso, ShadowDialog.getLatestDialog() can be used. So the solution is to have a DialogVerification class, to interact with dialogs, which uses Espresso on AndroidTests and ShadowDialog in Robolectric Test
• Crashlytics and other elements can be turned off, by using a custom Application class.
• Hilt requires a HiltTestApplication to test with.
• In Hilt FragmentScenarios are not supported, so to test Fragments, one way is to use a HiltActivity with EntryPoint and manage the ActivityScenario's lifecycle.
• mockwebserver.url()/.start() can throw NetworkOnMainThreadException exception on Android Device, one solution is to wrap it into a BackgroundThread execution, example: runBlocking { withContext(Dispatcher.IO) { mockwebserver.url("/") } }. reference = NetworkOnMainThreadException square/okhttp#3184
• resource access can be different between androidTest and RoboletricTest, can be mitigated by a config which uses assets in AndroidTest and resources in Robolectric.
• Advancing mainDispatcher should happen on the MainThread, so if livedata observers are executed, then it won't crash because TestRunnerThread is being used to touch them, one easy way is activityScenario.onActivity{ which runs on main thread.

[fknives]

Mention also the Pointer location developer options when dealing with touch events