Fix: ./gradlew test now passes on a clean tree (android#5) #89

2026-09-04T23:17:39Z

paulhitt commented

2026-09-04 23:17:39 +00:00

(Migrated from gitlab.com)

Confirmed exactly as filed: 15 red ScreenshotTests, all in the RELEASE
variant, all "Unable to resolve activity for Intent". The diagnosis in the
issue was right — androidx.compose.ui:ui-test-manifest is a
debugImplementation, and it is what declares the ComponentActivity
those tests launch, so the release variant's merged manifest has no such
activity.

The tempting fix is to add that dependency to release as well. Do
not. It exists to inject a test-only activity into the manifest, so
putting it on releaseImplementation would ship that into the APK. The
tests belong to the variant that can run them.

Excluded by name rather than by disabling testReleaseUnitTest
wholesale — everything else still runs in both variants, so a genuine
release-variant difference would still be caught.

And the first green was not evidence: clean followed by test
reported BUILD SUCCESSFUL in 3 seconds, which is far too fast to have run
anything. Re-run with --rerun-tasks and counted: debug 129, release 114,
JVM modules 933, 0 failures. The 15-test gap between the variants is
exactly the excluded screenshot tests, which is the shape that proves the
exclusion did what it says rather than taking the suite with it.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

Confirmed exactly as filed: 15 red `ScreenshotTest`s, all in the RELEASE variant, all "Unable to resolve activity for Intent". The diagnosis in the issue was right — `androidx.compose.ui:ui-test-manifest` is a `debugImplementation`, and it is what declares the `ComponentActivity` those tests launch, so the release variant's merged manifest has no such activity. **The tempting fix is to add that dependency to release as well. Do not.** It exists to inject a test-only activity into the manifest, so putting it on `releaseImplementation` would ship that into the APK. The tests belong to the variant that can run them. Excluded by name rather than by disabling `testReleaseUnitTest` wholesale — everything else still runs in both variants, so a genuine release-variant difference would still be caught. And the first green was not evidence: `clean` followed by `test` reported BUILD SUCCESSFUL in 3 seconds, which is far too fast to have run anything. Re-run with `--rerun-tasks` and counted: debug 129, release 114, JVM modules 933, 0 failures. The 15-test gap between the variants is exactly the excluded screenshot tests, which is the shape that proves the exclusion did what it says rather than taking the suite with it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

paulhitt commented

2026-09-04 23:17:39 +00:00

(Migrated from gitlab.com)

assigned to @paulhitt

paulhitt commented

2026-09-04 23:18:13 +00:00

(Migrated from gitlab.com)

mentioned in commit e5217f79ce

mentioned in commit e5217f79ce823918fce1bb35080b07d80d01799b

paulhitt (Migrated from gitlab.com) merged commit e5217f79ce into main

2026-09-04 23:18:13 +00:00

paulhitt commented

2026-09-04 23:20:16 +00:00

(Migrated from gitlab.com)

mentioned in issue #5

paulhitt commented

2026-09-09 19:01:20 +00:00

(Migrated from gitlab.com)

changed the description

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: extant2000/flamenet-messenger-android#89