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

Fix #3315: Set up UIAutomator with Bazel #3505

Merged
merged 44 commits into from
Aug 18, 2021

Conversation

FareesHussain
Copy link
Contributor

@FareesHussain FareesHussain commented Jul 20, 2021

Explanation

Fixes #3315

This pr introduces UI Automator with a BaseTest generated using Bazel

How to run UI Automator tests

Prerequisites:

  1. To be able to build oppia using bazel
    bazel build oppia
    
  2. Add adb to the environment (platform-tools) i.e, add the following line to the .bashrc or the file path according to the Operating System.
    export PATH=/home/<username>/Android/Sdk/platform-tools:$PATH
    
  3. java version 8 (Optional, only for uiautomatorviewer)
    java -version
    
    output:
    openjdk version "1.8.0_292"
    OpenJDK Runtime Environment (build 1.8.0_292-8u292-b10-0ubuntu1~18.04-b10)
    OpenJDK 64-Bit Server VM (build 25.292-b10, mixed mode)

Steps to run the tests:

  1. Build the BaseTest android_binary from the instrumentation module
    bazel build :oppia_test && bazel build //instrumentation:ExplorationPlayerTestBinary
    
  2. install the oppia_test.apk and the ExplorationPlayerTestBinary.apk
    adb install -r bazel-bin/oppia_test.apk && adb install -r bazel-bin/instrumentation/ExplorationPlayerTest.apk
    
  3. Run the instrumentation tests using am instrument command
    adb shell am instrument -w org.oppia.android.app.instrumentation/androidx.test.runner.AndroidJUnitRunner
    
2.1.Exploration.Player.Test.take.1.mp4

Checklist

  • The PR title starts with "Fix #bugnum: ", followed by a short, clear summary of the changes. (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".)
  • The PR explanation includes the words "Fixes #bugnum: ..." (or "Fixes part of #bugnum" if the PR only partially fixes an issue).
  • The PR follows the style guide.
  • The PR does not contain any unnecessary auto-generated code from Android Studio.
  • The PR is made from a branch that's not called "develop".
  • The PR is made from a branch that is up-to-date with "develop".
  • The PR's branch is based on "develop" and not on any other branch.
  • The PR is assigned to an appropriate reviewer in both the Assignees and the Reviewers sections.

… setup-uiautomator

� Conflicts:
�	third_party/maven_install.json
@FareesHussain FareesHussain self-assigned this Jul 20, 2021
BUILD.bazel Outdated
@@ -59,6 +59,7 @@ android_binary(
"versionName": "0.1-alpha",
},
multidex = "native", # TODO(#1875): Re-enable legacy for optimized release builds.
visibility = ["//visibility:public"],
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure what package_group I need to use here

Copy link
Member

Choose a reason for hiding this comment

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

We ought to create another binary specifically for tests, set that visibility to oppia_testing_visibility & set is as testonly.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

import org.junit.Test

/** Tests to load Oppia using UI Automator. */
class BaseTest {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This test suite is basically to check if the UI Automator is working fine or not
and to check if the app is loading as expected.

I'm navigating to the ProfileDashboard especially to verify if the we don't face similar errors we faced when using android_instrumentation_test target

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not using other test cases as the only purpose was to be able to run the end to end tests.
Other test cases may be used in future work.

Copy link
Member

Choose a reason for hiding this comment

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

Test suites should be specific to the things they are testing. In this case, I'd expect something like ExplorationPlayerTest. Please split this up/update it as needed to be specific to the sets of tests it will contain, and then update the packages & Bazel structure accordingly.

I think I also have feedback on how to change the Bazel structure, but it's hard for me to see the difference between which pieces a test-specific vs. generic. After this is addressed I should be able to give more specific feedback.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

@Test
fun baseTest_openProfileDashboard_titleExists() {
val skip_button = device.findObject(By.res("$OPPIA_PACKAGE:id/skip_text_view"))
skip_button?.let {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Null check, incase the app OnBoarding was already used once.

Comment on lines 84 to 86
"androidx.test.ext:junit": "1.1.3",
"androidx.test:core": "1.4.0",
"androidx.test:runner": "1.4.0",
Copy link
Contributor Author

@FareesHussain FareesHussain Jul 21, 2021

Choose a reason for hiding this comment

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

@BenHenning I've updated these version when we were trying the previous implementation.
Shall I revert them?

Copy link
Member

Choose a reason for hiding this comment

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

I lean toward not upgrading versions unless specifically needed.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

/** Tests to load Oppia using UI Automator. */
class BaseTest {
private val OPPIA_PACKAGE = "org.oppia.android"
private val LAUNCH_TIMEOUT = 5000
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I choose 5 seconds as per the Ui Automator examples I've referred to,
Tried using 1 sec and 2 secs both fail, 3 sec seems to be working.

Copy link
Member

Choose a reason for hiding this comment

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

We could also use 30 seconds. Generally, we see 10, 30, and 60 second timeouts, or 5 minutes as the longest possible (since Bazel will fail the test at that point) depending on the context. 30 seems more fitting here since there are a lot of things we may need to wait for on the emulator or device side for the test to actually start.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, I've also added a seperate timeout (TRANSITION_TIMEOUT) of 5 seconds to wait for the navigation between the activities, I used 5 seconds as minimum expecting that for the failure case the 30sec timeout would be very large for the activites.

@BenHenning
Copy link
Member

@FareesHussain given your comments, is this PR in a state ready to be in full review or should it be in draft?

Also, I probably won't be able to look at this for another day--sorry about that.

@FareesHussain
Copy link
Contributor Author

FareesHussain commented Jul 21, 2021

@FareesHussain given your comments, is this PR in a state ready to be in full review or should it be in draft?

Also, I probably won't be able to look at this for another day--sorry about that.

It is ready for review, I've added the comments just to explain some parts of the code.

Copy link
Member

@BenHenning BenHenning left a comment

Choose a reason for hiding this comment

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

Thanks @FareesHussain. Took a very high-level pass & left some comments--PTAL.

BUILD.bazel Outdated
@@ -59,6 +59,7 @@ android_binary(
"versionName": "0.1-alpha",
},
multidex = "native", # TODO(#1875): Re-enable legacy for optimized release builds.
visibility = ["//visibility:public"],
Copy link
Member

Choose a reason for hiding this comment

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

We ought to create another binary specifically for tests, set that visibility to oppia_testing_visibility & set is as testonly.

import org.junit.Test

/** Tests to load Oppia using UI Automator. */
class BaseTest {
Copy link
Member

Choose a reason for hiding this comment

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

Test suites should be specific to the things they are testing. In this case, I'd expect something like ExplorationPlayerTest. Please split this up/update it as needed to be specific to the sets of tests it will contain, and then update the packages & Bazel structure accordingly.

I think I also have feedback on how to change the Bazel structure, but it's hard for me to see the difference between which pieces a test-specific vs. generic. After this is addressed I should be able to give more specific feedback.

/** Tests to load Oppia using UI Automator. */
class BaseTest {
private val OPPIA_PACKAGE = "org.oppia.android"
private val LAUNCH_TIMEOUT = 5000
Copy link
Member

Choose a reason for hiding this comment

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

We could also use 30 seconds. Generally, we see 10, 30, and 60 second timeouts, or 5 minutes as the longest possible (since Bazel will fail the test at that point) depending on the context. 30 seems more fitting here since there are a lot of things we may need to wait for on the emulator or device side for the test to actually start.

Comment on lines 84 to 86
"androidx.test.ext:junit": "1.1.3",
"androidx.test:core": "1.4.0",
"androidx.test:runner": "1.4.0",
Copy link
Member

Choose a reason for hiding this comment

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

I lean toward not upgrading versions unless specifically needed.

@anandwana001
Copy link
Contributor

@FareesHussain Let's review it tomorrow while our meeting.

@anandwana001 anandwana001 added the PR don't merge - NEEDS UPDATE Corresponds to PRs that need to be updated with the latest develop changes before they can be merged label Jul 22, 2021
@FareesHussain
Copy link
Contributor Author

Tried

  • using executeShellCommand
  • manually clear storage within the instrumentation
  • activityManager.clearApplicationUserData()
  • deleting the cacheDir

None of them seems to work

Copy link
Member

@BenHenning BenHenning left a comment

Choose a reason for hiding this comment

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

@FareesHussain what specifically didn't work in each case?

@FareesHussain
Copy link
Contributor Author

@FareesHussain what specifically didn't work in each case?

I did mention this in the mail.

executeShellCommand("pm clear $OPPIA_PACKAGE")
and manually clearing the storage had the same error

https://gist.github.com/FareesHussain/b7ea9d5a8fdafe41f0dcc7536cd0111b

clearApplicationData() from the application context also had the same error
https://gist.github.com/FareesHussain/ec88b857f1d1cb1feef51f4c7580a47e

deleting the cacheDir doesn't have any change (I don't think it would reset the app as clearing application storage and deleting cache is a bit different), This doesn't crash the tests but also doesn't reset the app

Copy link
Member

@BenHenning BenHenning left a comment

Choose a reason for hiding this comment

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

Thanks @FareesHussain. One follow-up. I think the main thing left is ensuring data is properly reset between tests before this PR can be considered ready to merge (from my perspective).

@FareesHussain
Copy link
Contributor Author

FareesHussain commented Aug 15, 2021

Thanks @FareesHussain. One follow-up. I think the main thing left is ensuring data is properly reset between tests before this PR can be considered ready to merge (from my perspective).

running tests on fresh install / after clearing the application data, doesn't save the application data.
image
This was the test for 2.2 pr where the app starts from the onboarding screen for each test case.

Copy link
Contributor

@anandwana001 anandwana001 left a comment

Choose a reason for hiding this comment

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

everything LGTM,

Need to follow up with Ben's comment about clearing app data in every test case.
comment - #3505 (comment)

@oppiabot
Copy link

oppiabot bot commented Aug 16, 2021

Unassigning @anandwana001 since they have already approved the PR.

Copy link
Member

@BenHenning BenHenning left a comment

Choose a reason for hiding this comment

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

Thanks @FareesHussain. Left one follow-up comment with a suggestion to unblock this PR so that we can get it merged. PTAL.

@BenHenning BenHenning changed the title Fix #3315: Setup UIAutomator with Bazel Fix #3315: Set up UIAutomator with Bazel Aug 18, 2021
Copy link
Member

@BenHenning BenHenning left a comment

Choose a reason for hiding this comment

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

Since everything else looks good here, approving. Thanks @FareesHussain!

@BenHenning
Copy link
Member

Since there are no other open reviewer threads, merging this.

@BenHenning BenHenning merged commit a55f808 into oppia:develop Aug 18, 2021
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.

Introduce UIAutomator with bazel
4 participants