Android平台下如何确保开发者始终编写单元测试？是否可通过Lint、Ktlint或自定义代码实现检测？

Great question—making sure your team writes unit tests, and even pairs every critical method with a corresponding test, is a super common pain point for Android teams. Let’s break down how you can approach this, including tools, custom rules, and ways to handle edge cases like onCreate():

1. Can you set up constraints to ensure unit tests get written? #

You can’t 100% force someone to write tests (there’s always a workaround), but you can build strong guardrails that make skipping tests really hard. These checks can live in your CI/CD pipeline, pre-commit hooks, or even pop up in the IDE as real-time warnings—so developers can’t merge code without addressing missing tests.

2. How to ensure every method has a corresponding unit test? #

Not every method needs a test (looking at you, simple getters/setters), but for business logic methods, you have two main paths: code coverage tools and custom lint/ktlint rules.

Code Coverage with Jacoco #

Jacoco is the go-to tool for tracking which parts of your code are tested. You can set coverage thresholds in your build.gradle to fail the build if your team skips too many tests. For example:

jacoco {
    toolVersion = "0.8.10"
}

tasks.withType(Test) {
    jacoco.includeNoLocationClasses = true
    jacoco.excludeClassPatterns = ['jdk.internal.*']
}

task jacocoTestReport(type: JacocoReport) {
    dependsOn tasks.withType(Test)
    reports {
        xml.required = true
        html.required = true
    }
    afterEvaluate {
        classDirectories.setFrom(files(classDirectories.files.collect {
            fileTree(dir: it, exclude: [
                '**/R.class',
                '**/R$*.class',
                '**/BuildConfig.*',
                '**/Manifest*.*',
                '**/*Activity*.*', // Skip framework-bound components if needed
                '**/*Fragment*.*'
            ])
        }))
    }
}

// Add a check to enforce coverage thresholds
task jacocoTestCoverageVerification(type: JacocoCoverageVerification) {
    dependsOn jacocoTestReport
    violationRules {
        rule {
            limit {
                minimum = 0.8 // Require 80% overall coverage
            }
        }
        rule {
            element = 'METHOD'
            limit {
                minimum = 0.7 // Require 70% of methods to be tested
            }
        }
    }
}

build.dependsOn jacocoTestCoverageVerification

This way, if someone writes a method without a test, the build fails until coverage picks back up.

Custom Lint/Ktlint Rules #

For more granular control (like checking specifically if a method has a matching test), you can write a custom lint rule. Here’s the gist:

• Your rule scans production code methods, then checks the test source set for a corresponding test method (following your team’s naming convention, like test[MethodName] or should[DoSomething]).
• For Kotlin, you can extend Ktlint’s rule set; for Java/Kotlin mixed projects, use the Android Lint API.

A basic rule would:

1. Loop through all methods in your production classes.
2. Skip methods marked with a custom annotation (more on that for onCreate() later).
3. Check if there’s a test method in the matching test class that targets the production method.
4. If no test exists, throw a warning or error in the IDE.

3. Real-Time IDE Warnings for Missing Tests #

Once you’ve built your custom lint rule, integrate it into Android Studio. Developers will see a warning as soon as they write a method without a test—and the warning will disappear automatically once they add the corresponding test. Perfect for catching gaps early.

4. Ignoring Methods Like onCreate() #

For framework methods that don’t make sense to unit test (or are better tested with instrumented tests), create a custom annotation to exclude them from checks.

First, define the annotation:

@Retention(AnnotationRetention.SOURCE)
@Target(AnnotationTarget.FUNCTION)
annotation class SkipTestCheck

Then apply it to methods you want to ignore:

@SkipTestCheck
override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    // Your setup code here
}

Update your lint rule to skip any method annotated with @SkipTestCheck, and you’re good to go.

A Few Things to Keep in Mind #

• False positives: Your rule might miss tests that use non-standard naming (like shouldValidateInputWhenEmpty instead of testValidateInput). Either standardize test naming in your team, or tweak the rule to look for @Test annotations instead of just names.
• Don’t overdo it: Skip checks for trivial methods like getters/setters—this just adds unnecessary overhead. Focus on business logic that actually needs testing.
• CI/CD is key: Even if someone bypasses IDE warnings, make sure these checks run in your pipeline so untested code can’t get merged.

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