Background
The Android ComapeoPrefs JVM unit tests in android/src/test/java/com/comapeo/core/ComapeoPrefsTest.kt exercise the lambda-seam constructor only — the open(context) factory that actually wires SharedPreferences("com.comapeo.core.prefs", MODE_PRIVATE) and reads the plugin defaults via SentryConfig.loadFromManifest is untested.
This came up in the review of the diagnostics-toggle PR (#TBD). A regression in the production factory (wrong MODE_* constant, key-namespace typo in the production getSharedPreferences lambda, wrong default precedence between manifest/baked-in) wouldn't be caught by the existing tests.
What's needed
A Robolectric-based test (or instrumented test if Robolectric is too heavy to add) that:
- Verifies
open(context) returns a ComapeoPrefs reading from getSharedPreferences("com.comapeo.core.prefs", MODE_PRIVATE) — write through it via a separate SharedPreferences handle to the same file, observe via readDiagnosticsEnabled().
- Verifies the default-fallback precedence:
user write > plugin default > baked-in DEFAULT_DIAGNOSTICS_ENABLED. Plugin defaults come via SentryConfig.loadFromManifest, which reads <meta-data> from AndroidManifest.xml — easiest via Robolectric's RuntimeEnvironment.application.
- Verifies the storage key names by reading the on-disk prefs file directly after a write.
Why deferred
Adding Robolectric is a non-trivial dependency bump on the test classpath — out of scope for the toggle-persistence PR. The lambda-seam tests cover the read/write logic; this issue covers the wiring.
References
android/src/main/java/com/comapeo/core/ComapeoPrefs.kt
android/src/test/java/com/comapeo/core/ComapeoPrefsTest.kt
- Plan:
docs/sentry-integration-plan.md §9.8
🤖 Generated with Claude Code
Background
The Android
ComapeoPrefsJVM unit tests inandroid/src/test/java/com/comapeo/core/ComapeoPrefsTest.ktexercise the lambda-seam constructor only — theopen(context)factory that actually wiresSharedPreferences("com.comapeo.core.prefs", MODE_PRIVATE)and reads the plugin defaults viaSentryConfig.loadFromManifestis untested.This came up in the review of the diagnostics-toggle PR (#TBD). A regression in the production factory (wrong
MODE_*constant, key-namespace typo in the productiongetSharedPreferenceslambda, wrong default precedence between manifest/baked-in) wouldn't be caught by the existing tests.What's needed
A Robolectric-based test (or instrumented test if Robolectric is too heavy to add) that:
open(context)returns aComapeoPrefsreading fromgetSharedPreferences("com.comapeo.core.prefs", MODE_PRIVATE)— write through it via a separateSharedPreferenceshandle to the same file, observe viareadDiagnosticsEnabled().user write > plugin default > baked-in DEFAULT_DIAGNOSTICS_ENABLED. Plugin defaults come viaSentryConfig.loadFromManifest, which reads<meta-data>fromAndroidManifest.xml— easiest via Robolectric'sRuntimeEnvironment.application.Why deferred
Adding Robolectric is a non-trivial dependency bump on the test classpath — out of scope for the toggle-persistence PR. The lambda-seam tests cover the read/write logic; this issue covers the wiring.
References
android/src/main/java/com/comapeo/core/ComapeoPrefs.ktandroid/src/test/java/com/comapeo/core/ComapeoPrefsTest.ktdocs/sentry-integration-plan.md§9.8🤖 Generated with Claude Code