Fixed
Status Update
No update yet.
Comments
du...@google.com
This is a regression in the test support library 1.0 / Espresso 3.0.0. The issue does not occur if using the previous version of the testing support library 0.5, Espresso 2.2.2 or Espresso 2.3-alpha
du...@google.com
ta...@gmail.com
The ClassNotFoundException is being reported because the class could not be loaded because its base class could not be found. That behavior is correct if the class name has been explicitly specified. However, if the class name was obtained by scanning the path (which I assume is what is happening in this case) then it should ignore class loading errors.
Can you confirm that the test from step 2 is actually run even though a test failure is being reported for the unloadable class?
Can you confirm that the test from step 2 is actually run even though a test failure is being reported for the unloadable class?
ap...@google.com
The test cases are not being run. To prevent runtime crashes, I have the test cases which touch newer APIs configured with @SdkSuppress. The problem is occurring because the new runner is scanning the classpath and blows up whenever it sees something missing.
The same problem will occur with optional dependencies, like how Google Play Services contains MapFragment but the POM doesn't declare a dependency on support-v4. Clients of play services are expected to either not touch MapFragment or include support-v4 before touching the class. I do something similar with one of my own libraries, and anything consuming that library will fail to run tests unless I include an `androidTestCompile` dependency on support-v4.
The same problem will occur with optional dependencies, like how Google Play Services contains MapFragment but the POM doesn't declare a dependency on support-v4. Clients of play services are expected to either not touch MapFragment or include support-v4 before touching the class. I do something similar with one of my own libraries, and anything consuming that library will fail to run tests unless I include an `androidTestCompile` dependency on support-v4.
Description
Version used: 3.0.0-alpha08 or 3.0.0-alpha09
Devices/Android versions reproduced on: Samsung Galaxy S8 / Android 9
Starting with version 3.0.0-alpha08 of the Paging library, the MediatorResult.Success(false) value returned from a RemoteMediator.load(LoadType.REFRESH, state) call doesn’t trigger a RemoteMediator.load(LoadType.APPEND, state) call and doesn’t update PagingDataAdapter.loadStateFlow to notify that the refresh state has changed from LoadState.Loading to LoadState.NotLoading.
This bug can be reproduced by means of the following project, if you’ve changed the version of the Paging library it uses so that it’s equal to 3.0.0-alpha08 or 3.0.0-alpha09: