[Question] Proper way to test minified release build from test only module
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- android, kotlin
- Domain
- build-system, mobile, testing
Research direction
Start with the e2e module's buildTypes configuration and the com.android.test plugin variant handling described in the issue. Reproduce the test run against the app's minified release output, then determine whether the supported configuration can keep test code unminified while accepting the release mapping. Done means the UI tests run successfully against the minified app without shrinking the test code.
Written by the indexing model from the issue text.
Description
I have a multi-module Android project with a dedicated e2e module for UI tests that applies the com.android.test plugin.
The test sources live under the main source set (not androidTest).
The goal is to run UI tests against the minified release build to verify ProGuard/R8 shrinking/obfuscation doesn’t break anything and the app doesn't crash.
However, I don’t want to minify the test code itself.
Current Build Setup
In the e2e module I configured build variants like this:
buildTypes {
debug {
matchingFallbacks += listOf("release")
}
create("appTest") {
isMinifyEnabled = false
initWith(getByName("debug"))
}
}
Problem
When running tests, I get this error:
Mapping file found in tested application: .../app/build/outputs/mapping/release/mapping.txt
This means that the tested application has shrinking enabled.
For the test to work correctly, please enable shrinking in this test project as well
If I change the test build type to:
isMinifyEnabled = true
Then the test module fails because ProGuard/R8 shrinks the test code — and I don’t want the test code obfuscated or optimized.
- Dominant language
- Java
- Stars
- 1.2k
- Forks
- 342
- Avg merge
- 1d 14h
- Merged PRs (30d)
- 5
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from android/android-test
-
Difficulty 1/5 Under an hour Newbie friendliness 62/100
android/android-test#681 · 2 comments · 1 reaction ·
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
android/android-test#2507 · 1 comment ·
-
ξεκσνδξδ Open
Difficulty 5/5 Over a week Newbie friendliness 1/100
android/android-test#2499 ·
-
ησξξσ Open
Difficulty 5/5 Over a week Newbie friendliness 1/100
android/android-test#2498 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 38/100
android/android-test#2473 ·
All issues in android/android-test
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
elastic/gradle-plugins#157 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
cryptomator/hub#497 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
johanhaleby/occurrent#1120 ·