Android项目编写自动化测试用例及落地CI/CD的实现方案咨询

Hey there! As someone who’s shifted from testing into Android development, I totally get wanting to streamline your workflow with automation and CI/CD. Let’s break this down step by step—starting with how Android handles test directories (since you mentioned Maven’s setup) and moving into writing tests and setting up your pipeline.

1. Android’s Test Directory Structure (Maven Equivalent) #

Unlike Maven’s single test folder, Android splits tests into two standard directories right in your app module:

• src/test/java: For local unit tests (no device/emulator needed). These are for testing business logic, utility methods, or any code that doesn’t depend on Android framework APIs. Think of this as your "fast" test suite that runs directly on your machine.
• src/androidTest/java: For instrumented tests (requires a physical device or emulator). This is where you’ll write functional/UI tests that interact with the actual Android runtime—like testing login flows, navigation, or user interactions. This is closest to Maven’s functional test setup.

Both directories mirror your main app’s package structure, so you can keep test classes alongside the code they’re testing (e.g., com.yourapp.login.LoginViewModel would have a test in src/test/java/com/yourapp/login/LoginViewModelTest).

2. Writing Automation Test Cases #

Unit Tests (Local) #

Start here—they’re quick to write and run, perfect for validating logic without touching the UI. Use these tools:

• JUnit 4/5: The standard framework for writing test methods.
• Mockito: To mock dependencies (like repositories or APIs) so you can isolate the code you’re testing.

Example unit test for a login validation method:

import org.junit.Test;
import static org.junit.Assert.*;

public class LoginValidatorTest {
    @Test
    public void testValidEmail() {
        LoginValidator validator = new LoginValidator();
        boolean result = validator.isValidEmail("user@example.com");
        assertTrue("Valid email should return true", result);
    }

    @Test
    public void testInvalidEmail() {
        LoginValidator validator = new LoginValidator();
        boolean result = validator.isValidEmail("invalid-email");
        assertFalse("Invalid email should return false", result);
    }
}

Instrumented Functional/UI Tests #

For testing actual app behavior (like tapping buttons, filling forms), use Espresso—Google’s official UI testing framework. It’s stable, integrates well with Android Studio, and lets you write concise tests for user flows.

Example Espresso test for a login flow:

import androidx.test.ext.junit.rules.ActivityScenarioRule;
import androidx.test.ext.junit.runners.AndroidJUnit4;
import org.junit.Rule;
import org.junit.Test;
import org.junit.runner.RunWith;
import static androidx.test.espresso.Espresso.onView;
import static androidx.test.espresso.action.ViewActions.click;
import static androidx.test.espresso.action.ViewActions.typeText;
import static androidx.test.espresso.matcher.ViewMatchers.withId;
import static androidx.test.espresso.assertion.ViewAssertions.matches;
import static androidx.test.espresso.matcher.ViewMatchers.isDisplayed;

@RunWith(AndroidJUnit4.class)
public class LoginActivityTest {
    @Rule
    public ActivityScenarioRule<LoginActivity> activityRule = 
        new ActivityScenarioRule<>(LoginActivity.class);

    @Test
    public void testSuccessfulLogin() {
        // Enter valid credentials
        onView(withId(R.id.et_email)).perform(typeText("student@classelearn.com"));
        onView(withId(R.id.et_password)).perform(typeText("securepass123"));
        
        // Tap login button
        onView(withId(R.id.btn_login)).perform(click());
        
        // Verify we navigate to the dashboard
        onView(withId(R.id.dashboard_layout)).check(matches(isDisplayed()));
    }
}

For Jetpack Compose apps, use Compose Test instead—it’s designed specifically for testing Compose UIs.

3. Setting Up CI/CD (DevOps) for Your Project #

Once your tests are in place, you’ll want to automate running them on every code change, plus automate building and pushing updates to production. Here’s how to do this with GitHub Actions (free, widely used, and easy to set up):

Step 1: Add a CI Workflow File #

Create a .github/workflows/android-ci.yml file in your project root with this basic structure:

name: Android CI

on:
  push:
    branches: [ main, develop ] # Run on pushes to these branches
  pull_request:
    branches: [ main ] # Run on PRs to main

jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
          cache: gradle

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew

      - name: Run unit tests
        run: ./gradlew testDebugUnitTest

      - name: Run instrumented tests (using emulator)
        uses: reactivecircus/android-emulator-runner@v2
        with:
          api-level: 33
          script: ./gradlew connectedDebugAndroidTest

      - name: Build release APK
        run: ./gradlew assembleRelease

      # Optional: Upload APK to Firebase App Distribution for testing
      - name: Upload to Firebase App Distribution
        uses: wzieba/Firebase-Distribution-Github-Action@v1
        with:
          appId: ${{ secrets.FIREBASE_APP_ID }}
          token: ${{ secrets.FIREBASE_TOKEN }}
          groups: testers
          file: app/build/outputs/apk/release/app-release.apk

      # Optional: Deploy to Google Play (use Gradle Play Publisher)
      - name: Deploy to Google Play
        run: ./gradlew publishReleaseBundle
        env:
          PLAY_STORE_JSON_KEY: ${{ secrets.PLAY_STORE_JSON_KEY }}

Step 2: Configure Secrets #

In your GitHub repo, go to Settings > Secrets and variables > Actions and add:

• FIREBASE_APP_ID and FIREBASE_TOKEN (for Firebase App Distribution)
• PLAY_STORE_JSON_KEY (your Google Play Service account key, for publishing to production)

Step 3: Customize the Workflow #

• Adjust the api-level in the emulator step to match your app’s minimum SDK.
• Add manual approval for production deployments (using GitHub Environments) if you don’t want auto-pushes to production.
• For GitLab CI or Bitrise, the logic is similar—you’ll write a .gitlab-ci.yml or use their visual workflow builder to replicate these steps.

Pro Tips to Get Started #

• Start small: First get unit tests running in CI, then add instrumented tests (they’re slower, so you might want to run them only on main branch pushes initially).
• Use Firebase Test Lab: If maintaining emulators in CI is a hassle, you can run instrumented tests on Firebase’s cloud devices—supports multiple OS versions and devices without managing your own hardware.
• Integrate test coverage: Add ./gradlew createDebugCoverageReport to your workflow to generate coverage reports and track how much of your code is tested.

内容的提问来源于stack exchange，提问作者Uday