avito-tech / android-ui-testing Goto Github PK

Click on non-clickable view performs silently without any errors.
It's difficult to find a bug when it happens accidentally and it's better to check it manually.

Steps to reproduce:

• Unset all ARTIFACTORY_... environment params
• ./gradlew clean artifactoryPublish --info

Actual behavior:
Artifactory tasks completed without any sign of problems.

Expected behavior:
Artifactory task is failed

Which features to write about?
Which tests are missing?

problems with current design:

• not easy to expand/reuse, checks tightly coupled
• no group assertions (run all group, composite report)
• probably syntax

"what i don't like in espresso assertions" (already fixed):

• not typed, you can assert anything on every element
• recyclerView assertions are hacked actions in espresso-contrib library
• you can't add obligatory action before assertion (it makes sense in recyclerView with scroll at least)
• unable to customize error messages

Synax proposal:

assertJ Like:

assertThat([description], element).<autocomplete with typed assertions>

for grouped (not sure if it's possible just like that):

assertThat([description]) {
       element.<assertion>
       element2.<assertion>
}

Open top level function

https://github.com/robstoll/atrium has brilliant idea to leave top-level function naming and config open for library user, we should consider it too

EditTextTest

at com.avito.android.ui.test.EditTextTest.writesCyrillicText(EditTextTest.kt:33)
        at java.lang.reflect.Method.invoke(Native Method)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
        at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
        at android.support.test.rule.ActivityTestRule$ActivityStatement.evaluate(ActivityTestRule.java:527)
    ...
     Caused by: java.util.concurrent.ExecutionException: java.lang.NoSuchFieldException: No field mIInputContext in class Landroid/view/inputmethod/InputMethodManager; (declaration of 'android.view.inputmethod.InputMethodManager' appears in /system/framework/framework.jar!classes2.dex)

It's necessary to assert there no specified item in list.

It fails even I call .doesNotExist() on element

https://developer.android.com/topic/libraries/testing-support-library/release-notes#espresso_302_runner_102_rules_102_monitor_102_androidtestorchestrator_102_2018_04_24

val view: PageObjectElement = typedItemByMatcher(withId(R.id.payment_loading_view)) will actually find item by position:

Check descendant view with id: com.avito.android.dev:id/payment_loading_view on 0-th item matching: holder with view

because it calls the overload typedItemByMatcher( matcher: Matcher<View>, position: Int = 0 )

Might be confusing.

DoD: user can compose the best runner for own needs, based on AndroidJUnitRunner

Useful hacks are not obvious, one has to know the internals of AndroidJUnitRunner to create a custom testing experience.

Here we introduce samples of what one can get.

Also, is it really appBar? not a collapsing layout?

load reports on test lab non zero result

The current implementation has several disadvantages:

• There is no default implementation for indexed access to list elements like operator fun get(position: Int): T, first(): T, last(): T, etc.
• childFactory creates only PageObjectElements, there is no way to create custom children for list item
• In most cases we have to manually pass the same actions/checks params to PageObjectElement constructor
• #7

Also, ListActions class has a few members that are not actions (like items, translationY, verticalOffset, horizontalOffset), we can make them private

Travis? circleCI?
We need best choice for instrumentation tests