Repository navigation
Conversation
Coverage (unit tests)No unit baseline recorded in
Line and branch coverage from unit test reports. History is recorded in |
This file contains hidden or 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
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.
@EnableMapsShadowshas never registered any shadows. It puts@Config(shadows = [...])on an annotation class, and Robolectric does not read@Configthrough meta-annotations. Every test that used it got the Maps shadows from therobolectric.propertiesthe library ships (found in #5). This adds a runner that registers the shadows on its own, so that file can be removed later.MapsRobolectricTestRunnerextendsRobolectricTestRunnerand passes it an injector that binds aGlobalConfigProviderwith the 16 Maps shadows:@Configon the class or method still merges on top (sdk, extrashadows, and so on).buildGlobalConfig(), the obvious hook, and it does not work: Robolectric stores its result in a static field that only the first runner created in the JVM gets to set. With that version, 54 of 131 tests failed once the properties file was gone.@EnableMapsShadowsis now@Deprecatedand points to the runner. It is not removed, since rc01 users may have it on their tests.Migration in this repo: every test, sample, template and doc snippet that used
@RunWith(RobolectricTestRunner::class)plus@EnableMapsShadowsnow uses@RunWith(MapsRobolectricTestRunner::class). ThegetMapBlocking()error messages point at the runner too. The#Lx-Lyregion links in the skills were recomputed against the moved[START]/[END]tags. The module README has a new "Registering the Maps shadows" section, coveringAndroidJUnit4tests and the fact that an app with its own rootrobolectric.propertiesloses the shipped one.robolectric.propertiesstill ships. The plan is to remove it before 1.0.0.Tests (
MapsRobolectricTestRunnerTest):MAPS_SHADOWS;MAPS_SHADOWSlists every@Implementsclass in the shadows package, so it cannot drift the way the package-level properties file did (10 of 16);@Config(sdk = [33])run through the runner gets both SDK 33 andShadowMapView.I mutation-checked the first two: dropping a shadow from the list, or binding Robolectric's default config instead, each fails its test.
Proof that the runner works without the file: in a scratch checkout of this branch, with all four
robolectric.propertiesremoved (the shipped ones and the module's test copy),./gradlew test --rerun-tasks --no-build-cacheruns 131 tests, 0 failing.Ran
./gradlew test lint spotlessCheck apiCheck docs:dokkaGenerate --rerun-tasks --no-build-cache: green. The API change is additive (new class plus aMAPS_SHADOWSlist).Conflicts: #9 moves the
:apptests edited here, and #7 touches some of the same skill files. Whichever merges later needs a rebase.Replaces #5.