Fixed
Status Update
Comments
ga...@google.com <ga...@google.com> #2
The issue seems to be the unit tests setup in the IDE. When running unit tests, I can see that Mockito is in the classpath when running unit tests from the IDE.
[Deleted User] <[Deleted User]> #3
We also experienced an issue that seems pretty similar to this. We have a unit test inside our app that calls a method from a library (our own). The library is included as a dependency via our Maven repo (as an AAR). Lets call this one library A. This method in turn calls a method of another library (library B), this one is a third-party dependency. Now our unit test fails with a NoClassDefFoundError when trying to call the method from library B (the transitive one). Both libs are included as implementation dependency in the respective projects.
When we run the test via Gradle, everything works fine. Also when we included library A as a local Gradle module, the tests executed inside Android Studio without any issues.
We could reproduce this bug with AS 3.4 as well as 3.5 Beta on macOS as well as Windows.
I hope I could explain our issue, if you think it's a separate problem I can file another ticket if you want.
When we run the test via Gradle, everything works fine. Also when we included library A as a local Gradle module, the tests executed inside Android Studio without any issues.
We could reproduce this bug with AS 3.4 as well as 3.5 Beta on macOS as well as Windows.
I hope I could explain our issue, if you think it's a separate problem I can file another ticket if you want.
ja...@gmail.com <ja...@gmail.com> #4
I should have also mentioned why this matters. We have Robolectric in one library module. It's not supposed to be used in other test suites. Currently it's possible to write AndroidJUnit4 unit tests in other modules and they will pass locally in Android Studio until the CI system rejects it later. There are probably other scenarios where reflective libraries are misbehaving because they are detecting unexpected adapters / extensions on the classpath at runtime.
vi...@google.com <vi...@google.com>
ar...@google.com <ar...@google.com> #5
Reassigning this to Bradley, instead of the the triage tool.
sm...@google.com <sm...@google.com> #6
Unit tests now run via Gradle which should remove this issue with the IDE classpaths. On the latest version of Android Studio the attached test projects' tests correctly pass. This should have been the case for a while now.
Description
Build #AI-183.5429.30.34.5452501, built on April 9, 2019
JRE: 1.8.0_152-release-1343-b01 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
macOS 10.14.5
Android Gradle Plugin 3.4.0
Gradle 4.5.1
Libraries that declare testImplementation dependencies should not add these dependencies to the runtime classpath in consuming modules. Android Studio is currently behaving this way when running unit tests.
The sample project attached to this issue has example unit tests that fail in Android Studio. The project also has instrumented tests that pass in Android Studio. This demonstrates that the issue appears to only affect unit test builds. All of the tests pass when run on the command line with the Gradle wrapper.