Testing

Executive summary

Costco Android has a mature, multi-layered test stack: ~170 unit-test files, ~80 instrumentation tests across 30+ modules. The unit-test foundation is JUnit 4 + MockK + Turbine + a custom MainCoroutineRule; UI automation uses Compose UI Test + Espresso + UiAutomator with Karumi Shot for screenshot regression. JaCoCo enforces a 40.81% coverage threshold, which is low for a retail-scale codebase. There are concrete gaps around library version drift (Hilt-testing 2.28-alpha vs Hilt 2.56), absent Macrobenchmark / baseline profiles, and no Firebase Test Lab integration in CI.

1. Tooling inventory

All versions sourced from gradle/libs.versions.toml and the Costco/build.gradle file.

2. Unit testing — what's in place

Test taxonomy

The ~170 unit-test files break down (approximately) as:

• ~60 in the Costco app module covering legacy logic (Pharmacy, ShoppingList, FindAStore, locale, webview) — the highest concentration of Java tests.
• ~40 across feature/* modules — ViewModel, UseCase, Mapper, Util tests. Examples: AccountViewModelTest, ProductDetailPageLandingViewModelTest, NativeSearchUseCaseImplTest, ProductPricingCardModelMapperTest.
• ~70 across shared/* modules — repository tests, network mappers, formatters. Examples: BffLayerRepositoryImplTest, ContentstackDeliveryRepositoryImplTest, SharedMembershipServiceTest, StringUtilsKtTest, FirebaseRemoteLoggerTest.

Conventions used

Concrete file references

• ViewModel test pattern: Costco/src/test/java/com/costco/app/android/ui/pharmacy/PharmacyViewModelTest.kt
• Mapper test pattern: Costco/src/test/java/com/costco/app/android/warehouse/data/mapper/WarehouseMapperImplTest.kt
• Repository test pattern: feature/productdetaillanding/src/test/java/com/costco/app/productdetaillanding/repo/ProductDetailPageLandingRepositoryImplTest.kt
• Hand-written fake: shared/auth/src/test/java/com/costco/app/auth/util/FakeDataStore.kt
• Custom coroutine rule (7 copies): feature/discover/src/test/java/com/costco/app/shop/MainCoroutineRule.kt · feature/account/src/test/java/com/costco/app/account/MainCoroutineRule.kt · feature/warehouse/src/test/java/com/costco/app/warehouse/MainCoroutineRule.kt · 4 others

3. Automation / UI testing — what's in place

Test types running on device / emulator

Page Object Model

The androidTest tree under the main app module follows an organized POM-style structure with one file per surface:

• Costco/src/androidTest/kotlin/com/costco/app/android/data/source/local/costcoUITests/pages/HomePageTest.kt
• Costco/src/androidTest/kotlin/com/costco/app/android/data/source/local/costcoUITests/pages/ShopPageTest.kt
• Costco/src/androidTest/kotlin/com/costco/app/android/data/source/local/costcoUITests/pages/SavingsPageTest.kt
• Costco/src/androidTest/kotlin/com/costco/app/android/data/source/local/costcoUITests/pages/SavingsOffersTest.kt
• Costco/src/androidTest/kotlin/com/costco/app/android/data/source/local/costcoUITests/pages/OnBoardingTest.kt
• Centralized test data: .../costcoUITests/TestConstant.kt

UiAutomator falls in for system dialogs (e.g. permission prompts) — see UiDevice.getInstance() usage in HomePageTest.kt.

Compose UI Test pattern

Component-level tests use createComposeRule() + composeTestRule.setContent { … } to mount the Composable in isolation, then assert on semantics nodes:

@RunWith(AndroidJUnit4::class)
@HiltAndroidTest
class DefaultNavHeaderTest {
  @get:Rule(order = 0) val hiltRule = HiltAndroidRule(this)
  @get:Rule(order = 1) val composeTestRule = createComposeRule()

  @Test
  fun renders_brand_logo() {
    composeTestRule.setContent { CostcoTheme { DefaultNavHeader(...) } }
    composeTestRule.onNodeWithTag("brand_logo").assertIsDisplayed()
  }
}

Test runner configuration

The app module declares two runners depending on task:

• Default: androidx.test.runner.AndroidJUnitRunner
• For screenshot tests: com.karumi.shot.ShotTestRunner
• Test orchestration: execution 'ANDROIDX_TEST_ORCHESTRATOR' — each test runs in a separate process to prevent state leakage.

Files: Costco/build.gradle (lines 69–80)

4. Coverage

JaCoCo is wired in via jacoco.gradle at the repo root (toolVersion 0.8.8), with a coverageCheck task that fails the build if line coverage drops below 40.81%.

5. CI integration

Test execution runs on Azure Pipelines. The pipeline file is azure-pipelines.yml (~50 KB). Highlights:

• PR triggers on develop, release-*, features/*.
• Two-stage flow: Classify (PR metadata) → PR build (gradle build + tests).
• Test results published via testResultsFiles: '**/TEST-*.xml'.
• Gradle parallelism enabled (--max-workers).
• Separate pipeline for security: azure-pipelines-nowsecure.yml runs NowSecure mobile security scans.
• BrowserStack integration is referenced for web testing — no Firebase Test Lab.

6. Findings

7. Recommended target state

Specific findings in this category