Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue/242-3 #286

Merged
merged 50 commits into from
Oct 12, 2021
Merged

Issue/242-3 #286

merged 50 commits into from
Oct 12, 2021

Conversation

matzuk
Copy link
Member

@matzuk matzuk commented Oct 5, 2021

Hi @sergio-sastre!
Again, thank you very much for your contribution. You've done a great job!
So, I spent some time thinking about how to make Robololectric support more seamless for users. I've decided to evolve your solution in the following things:

  1. A user doesn't need to add sharedTest = true. All tests can be run on the JVM environment and Instrumental environment simultaneously without additional configurations (except Robolectric configuration sure). With the previous solution, reusage of the test on both environments was a little bit trickier.
  2. KautomatorConfig is transformed into InstrumentalDepsAssistant and related classes. It allows to reduce boilerplate code and leave some Device classes and methods working even on the JVM environment.
  3. A user can know and use the environment state through isInstrumentalEnvironment property in TestContext and Kaspresso.Builder classes.
  4. All manipulations with inteceptors are living inside Kaspresso class. But, a user can do similar things in Kaspresso.Builder too.

sergio-sastre and others added 27 commits July 13, 2021 20:50
The tests do run successfully on the emulator but not on the JVM yet.  We still need to separate the Kautomator config to make it possible
Was also necessary to downgrade the version of androidXCore to avoid gradle error (was including different versions  of the same dependencies, making gradle fail when running the tests on the JVM)
It is the class that decides how to initialize the Kautomator dependent classes, since Robolectric does not support UiAutomator -> Kautomator
This text contains very long text. Therefore, it needs to use the AutoScrollInterceptor to run successfully as Instrumentation as well as JVM test
Code review suggestion
# Conflicts:
#	allure-support/src/main/kotlin/com/kaspersky/components/alluresupport/AllureSupportKaspressoBuilder.kt
#	kaspresso/src/main/kotlin/com/kaspersky/kaspresso/device/accessibility/AccessibilityImpl.kt
#	kaspresso/src/main/kotlin/com/kaspersky/kaspresso/device/exploit/ExploitImpl.kt
#	kaspresso/src/main/kotlin/com/kaspersky/kaspresso/device/viewhierarchy/ViewHierarchyDumperImpl.kt
#	kaspresso/src/main/kotlin/com/kaspersky/kaspresso/kaspresso/Kaspresso.kt
Copy link
Contributor

@sergio-sastre sergio-sastre left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@matzuk
Hi there, I got some time to review it! Thanks for the changes!
I like the approach in general, and agree on the sharedTest flag not being needed.

There are 2 points to review:

  • @RequiresApi(Build.VERSION_CODES.N) for uiAutomation -> unless there is any other reason, it should be @RequiresApi(Build.VERSION_CODES.JELLY_BEAN_MR2), API 18 as stated in the docu
  • ActivitiesImpl takes instrumentation as argument. Not sure whether it is allowed on the JVM but it could crash in that case?

kaspresso/build.gradle.kts Show resolved Hide resolved
targetCompatibility = JavaVersion.VERSION_1_8
}

kotlinOptions {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And this too

@@ -9,8 +9,37 @@ android {
testInstrumentationRunnerArguments["clearPackageData"] = "true"
}

sourceSets {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be part of convention.android-base plugin

testImplementation(libs.androidXTest)
testImplementation(libs.robolectric)

debugImplementation(libs.fragmentTesting)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using debugImplementation configuration for test dependencies is awful. Do we really need this dependency?


androidTestUtil(libs.orchestrator)

testImplementation(libs.runner)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the AndroidX Test Runner needed for unit tests?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants