Calendar Notifications Plus uses dorny/test-reporter for displaying test results directly in GitHub. This document explains how our test reporting is configured and how to interpret the results.
The test reporting system provides:
- Immediate feedback on test results for each pull request
- Detailed views of which tests passed/failed
- Historical test data to track progress
- Integration with GitHub Checks API
- Code coverage reporting via JaCoCo
Our test reporting is integrated into three key parts of our CI workflow:
In the main workflow (.github/workflows/actions.yml
), test-reporter is configured to run directly after tests complete:
- Unit Tests: Reports are generated from JUnit XML files in the unit test job
- Integration Tests: Reports are generated from instrumentation test XML files
These reports provide immediate feedback on test results and appear as GitHub Checks for each commit.
A dedicated job in the main workflow processes code coverage data:
- Downloads coverage artifacts from unit and integration tests
- Generates detailed coverage reports using JaCoCo
- Creates coverage badges for line and branch coverage
- Posts coverage summary as a PR comment
- Archives HTML reports for detailed inspection
A separate workflow (.github/workflows/test-summary.yml
) runs when the main workflow completes to provide:
- Unit test summary
- Integration test summary
- Combined test overview
- Coverage report summary with badges
- GitHub Actions Summary with badges
This provides a consolidated view of all test results and coverage across the build.
Test reports appear in several places:
- Pull Request Checks: Test results appear as check runs in the PR
- GitHub Actions Summary: Look for the summary tab in the Actions run
- PR Comments: Each PR gets a comment with coverage metrics
- Artifacts: Raw test results and coverage reports are available as artifacts
Our CI pipeline generates comprehensive code coverage data:
Two primary metrics are tracked:
- Line Coverage: Percentage of code lines executed during tests
- Branch Coverage: Percentage of decision branches executed during tests
Coverage data is available in multiple formats:
- HTML Report: Interactive HTML report for detailed analysis
- XML Report: Raw JaCoCo XML data
- Badges: SVG badges with current coverage percentages
- PR Comment: Summary of coverage posted to each PR
We've established baseline coverage requirements:
- Overall Project: Minimum 30% line coverage
- Changed Files: Minimum 60% line coverage for newly modified files
These thresholds help maintain and improve code quality over time.
When tests fail:
- Check the test name and failure message in the report
- Look for the specific test file and method involved
- Examine the stack trace for the root cause
- Review the test coverage report for related code areas
To replicate the CI test environment locally:
# Run unit tests
cd android && ./gradlew :app:testX8664DebugUnitTest
# Generate XML reports
cd android && ./gradlew :app:testX8664DebugUnitTest --tests="*" -i
# Generate coverage report
cd android && ./gradlew :app:jacocoAndroidTestReport
The test-reporter uses two primary formats from our build:
- JUnit XML: Generated by Android's standard test runners
- Jacoco XML: For code coverage reporting
Common issues with test reporting:
- Missing Reports: Check the test task output paths
- Path Patterns: Verify glob patterns match the actual file locations
- Report Format: Ensure the selected reporter matches the XML format
- Coverage Data: Verify that
testCoverageEnabled true
is set in the build.gradle file