Fix #5334, #3618: Fix broken //instrumentation builds #5335
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was done by removing the //testing dependency and, instead, having instrumentation targets depend on the direct module within //testing that they need to build. This module & its corresponding implementation binding (and tests) needed to be moved out of //testing and into their own /firebase package.
BenHenning
changed the title
BenHenning
commented
Feb 7, 2024
|
Looks like the codeowner file will need to be updated. I'll send that in a follow-up commit & verify that check passes. I think this can be sent for review if all the other checks pass with the current changes. |
|
It looks like the only failure was CODEOWNERS, and it's now passing with the latest commit. This PR is ready to go into review now. |
|
PTAL @adhiamboperes for whole PR. PTAL @seanlip for CODEOWNERS changes. |
BenHenning
changed the title
|
I also just noticed from work in #5138 that no test declarations were added for 2 of the new tests under //domain/src/test/java/org/oppia/android/domain/auth, so I added them here since the PR is already out. |
BenHenning
commented
Feb 8, 2024
6 tasks
adhiamboperes
approved these changes
Feb 8, 2024
|
Hi @BenHenning, this PR is ready to be merged. Please address any remaining comments prior to merging, and feel free to merge this PR once the CI checks pass and you're happy with it. Thanks! |
|
Thanks for the reviews! Synced with latest and am enabling auto merge. |
|
Unexpected Gradle flake in one of the SurveyProgressControllerTest tests; re-running (and checking via Bazel locally if this is a reliable flake). |
BenHenning
added a commit
that referenced
this pull request
Feb 14, 2024
…art of #5308: Fix a variety of dev platform-specific issues [Blocked: #5335] (#5138) ## Explanation Fixes #5303 Fixes #5304 Fixes #5305 Fixes #5306 Fixes #5309 Fixes part of #5307 Fixes part of #5308 This PR fixes a variety of issues that were discovered while trying to begin development on #4929 with a different workstation than I usually build on. Some of the issues were outright problems at the outset, but others were discovered when trying to fix those issues (e.g. during test utility upgrades). Specific issues that were found and fixed: - #5303: ``AssertionHelpers.assertThrows`` didn't handle cases when trying to catch an ``AssertionError`` itself (such in the case of ``TestGitRepositoryTest``). This could result in false positives, and it has since been fixed. Plus, the changes to ``AssertionHelpers`` also removes the dependency on Kotlin reflection. - #5304: ``LoggingIdentifierController`` could have ID generation inconsistencies between environments due to how its ``Random`` instance was initialized. This could also result in a test order issue if a subset of tests were run, or run in a different order. The controller has been updated to have better robustness against the order in which IDs are generated which fixes the test and environment determinism issues. \ \ The fix was essentially generating ID-specific seeds for ID-specific randoms that all originate from the application seed, and are always generated in the same order deterministically at the creation time of the controller. This fixes the IDs being generated in different orders leading to inconsistencies. Note that this is why ID changes are seen in a variety of tests (since there are now new seeds being used for generating these IDs as a by-product of the robustness improvements). - #5305: ``model/src/main/proto/BUILD.bazel`` needed a fix due to a build warning (that only occurs when trying to build all targets). - #5306: ``TestGitRepository`` was made more robust by better managing and setting the configured user & email used in its Git commands. The utility now manages a locally set configuration for each rather than relying on the global configuration (which may not be present on all systems, hence the original issue). Some other improvements in error detection were also added. Note that this likely wasn't discovered in CI because it seems that GitHub CI _does_ set up a Git user & email automatically, as do most people who work on the project. - #5307 & #5308: ``ActivityTestRule`` is now deprecated in favor of ``ActivityScenarioRule`` since it can interact with activities outside their lifecycle. However, the scenario rule is also not good to use anymore since it can result in partial dependencies being initialized before test-only platform parameter states can be overridden. This PR introduces a new pattern to prevent using either of these rules, and the mentioned issues can be used to track the remaining tests that need to be cleaned up following this PR. - #5309: ``ProfileAndDeviceIdFragmentTest`` is environment and order-dependent due to out-of-order platform parameter initialization. This issue ultimately arose from test parameters being initialized after they're needed in the launched UI. It is necessary when there are environment differences (e.g. local vs. CI) or when running certain tests individually. This was fixed by removing the usage of ``ActivityScenarioRule`` and instead managing the fragment's test activity lifecycle directly. \ \ Separately, the test performs proto comparisons that can be machine-dependent. It seemed the test was suffering from some proto encoding inconsistencies that seem to occur between some development machines vs. on CI. The fix improves the test's robustness by extracting the raw encoded string, verifying that the other outputs in the intent message correctly correspond to that string, and that the string (as a parsed proto) contains the correct values. As a result, the test no longer depends on a hardcoded encoding value to be present for verification. This does result in a slightly lengthier test with more logic, but should be more stable in the long-term. Some other miscellaneous notes: - ``testCreateLearnerId_verifyCreatesCorrectRandomValue`` was removed from ``LoggingIdentifierControllerTest`` because it wasn't actually providing useful testing value. The application seed is not itself part of the class's public API. Instead, the ID generation methods should be ultimately verified. - ``ComputeAffectedTestsTest`` had a shard increase to 24 and ``BazelClientTest`` has now been sharded to 4 (ditto for ``GenerateMavenDependenciesListTest`` and ``MavenDependenciesListCheckTest``). Both were done to help distribute the more expensive tests in each suite across multiple runners to try and reduce the long-tail of script test runs. More optimization will probably be useful in the future. Note also that some of these tests are *much* slower on certain systems (the one I've been working on, for instance), hence the need for these adjustments. - ``testEnsureNextResultIsSuccess_failureThenSuccess_notified_throwsException`` was removed from ``DataProviderTestMonitorTest`` since it *seems* that it wasn't actually written correctly (and the issue wasn't discovered until ``assertThrows`` was fixed). Per the existing test coverage, it doesn't seem necessary to try and fix the test so it was instead removed. - ``ProfileAndDeviceIdFragmentTest`` changes led to a new ``EventLogSubject.hasNoProfileId`` being added. - There are a few miscellaneous script infrastructure changes that were pulled into this PR in preparation for downstream work. Specifically: - ``ComputeAffectedTests`` now allows for its command executor to be used for Bazel operations (which provides its tests with a bit more execution flexibility). Its tests were also updated to use a longer timeout for commands to try and improve test stability. ``BazelClientTest`` was similarly updated. - ``TestBazelWorkspace`` was updated to: - Have better workspace initialization robustness (since the workspace can actually be generated at several different points, not singularly with a call to ``initEmptyWorkspace``). - Add a ``.bazelrc`` file to disable bzlmod (since it causes network stability issues in some environments when using newer Bazel versions even if the project isn't upgraded, and we don't use bzlmod yet, anyway). - Add a ``.bazelversion`` file to ensure that tests are using the same Bazel version as the project build. - ``AuthenticationControllerTest`` was largely updated since the changes to ``assertThrows`` behavior revealed that the failure test wasn't actually correctly verifying an exception was being passed (since it isn't actually being thrown; the test was a false positive possibly because it was using ``Throwable``, but I didn't dig into exactly why it was passing before). The changes ensure that the callbacks are actually verified rather than the user result (since there's a separate test to do that), as well as the exception's failure message. ## Essential Checklist - [x] The PR title and explanation each start with "Fix #bugnum: " (If this PR fixes part of an issue, prefix the title with "Fix part of #bugnum: ...".) - [x] Any changes to [scripts/assets](https://github.com/oppia/oppia-android/tree/develop/scripts/assets) files have their rationale included in the PR explanation. - [x] The PR follows the [style guide](https://github.com/oppia/oppia-android/wiki/Coding-style-guide). - [x] The PR does not contain any unnecessary code changes from Android Studio ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#undo-unnecessary-changes)). - [x] The PR is made from a branch that's **not** called "develop" and is up-to-date with "develop". - [x] The PR is **assigned** to the appropriate reviewers ([reference](https://github.com/oppia/oppia-android/wiki/Guidance-on-submitting-a-PR#clarification-regarding-assignees-and-reviewers-section)). ## For UI-specific PRs only N/A since all of the changes in this PR are infrastructural or only affect tests. --------- Co-authored-by: Adhiambo Peres <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explanation
Fixes #5334
Fixes #3618
The root issue is that
//instrumentationwas updated in #5098 to depend on//testing. However, the current dexer that we use in Bazel has troubles dexing certain dependencies (including Robolectric & Mockito), and since//testingtransitively pulls in these test dependencies, the instrumentation test binaries fail to build.The main fix is isolating the new Firebase testing dependencies to their own package instead of needing to pull in
//testing. This resulted in some broad but trivial changes in other tests throughout the codebase. Note that I opted for just updating//testingrather than all affected deps lists to keep things a bit simpler (stricter deps will fix this in a later PR as part of the Bazel chain using automation to make things a lot simpler). This addresses issue #5334.To keep this from happening again in the future, new smoke build tests were added for instrumentation tests and the top-level
//instrumentation:oppia_testto ensure that ourComputeAffectedTestsutility correctly identifies and picks up these tests as part of the CI run when relevant (historically, instrumentation tests have been completely ignored in CI since they can't be run yet; note this doesn't include the instrumentation package's unit tests since these use Robolectric and are included in CI runs). This addresses issue #3618. Note that this was verified as working using an initial commit to this PR that only added the new smoke tests and verifying that//instrumentation:oppia_test_binary_smoke_testis now picked up and fails, per the log output (& CI results):Finally, note that there are a couple of new test targets added under
//domain/src/test/java/org/oppia/android/domain/authsince it was noticed during the development of #5138 that these were missed in an earlier commit to develop (and should be run in both Bazel & Gradle test passes).Essential Checklist
For UI-specific PRs only
N/A -- This change only targets & fixes test-only infrastructure.