다음은 CI 시스템에서 사용할 수 있는 몇 가지 일반적인 자동화 형식입니다.
기본 작업
빌드: 프로젝트를 처음부터 빌드하여 새 변경사항이 올바르게 컴파일되고 모든 라이브러리와 도구가 서로 호환되는지 확인합니다.
린트 또는 스타일 검사: 선택사항이지만 권장되는 단계입니다. 스타일 규칙을 적용하고 정적 분석을 실행하면 코드 검토를 더 간결하고 명확하게 수행할 수 있습니다.
로컬 또는 호스트 측 테스트: 빌드를 실행하는 로컬 머신에서 실행됩니다. Android에서는 일반적으로 JVM이므로 빠르고 안정적입니다. Robolectric 테스트도 포함됩니다.
계측 테스트
에뮬레이터 또는 실제 기기에서 실행되는 테스트에는 기기가 부팅되거나 연결될 때까지 대기하는 프로비저닝, 복잡성을 더하는 기타 작업이 필요합니다.
CI에서 계측 테스트를 실행하는 방법에는 여러 가지가 있습니다.
- Gradle 관리 기기는 사용할 기기 (예: 'API 27의 Pixel 2 에뮬레이터')를 정의하는 데 사용할 수 있으며 기기 프로비저닝을 처리합니다.
- 대부분의 CI 시스템에는 Android Emulator를 처리하기 위한 서드 파티 플러그인('작업', '통합' 또는 '단계'라고도 함)이 함께 제공됩니다.
- Firebase Test Lab과 같은 기기 팜에 계측 테스트를 위임합니다. 기기 팜은 높은 안정성을 위해 사용되며 에뮬레이터 또는 실제 기기에서 실행할 수 있습니다.
성능 회귀 테스트
앱 성능을 모니터링하려면 벤치마크 라이브러리를 사용하는 것이 좋습니다. 개발 중에 성능 테스트를 자동화하려면 일관되고 현실적인 테스트 결과를 보장하는 실제 기기가 필요합니다.
벤치마크를 실행하는 데 시간이 오래 걸릴 수 있으며, 특히 벤치마킹하는 코드 및 사용자 여정의 범위가 많은 경우 시간이 오래 걸릴 수 있습니다. 병합된 기능 또는 커밋마다 모든 벤치마크를 실행하는 대신 야간 빌드와 같이 정기적으로 예약된 유지보수 빌드의 일부로 실행하는 것이 좋습니다.
성능 모니터링
걸음 맞춤을 사용하여 성능 회귀를 모니터링할 수 있습니다. 단계 맞춤은 현재 빌드와 비교할 이전 빌드 결과의 롤링 기간을 정의합니다. 이 접근 방식은 여러 벤치마크 결과를 하나의 회귀별 측정항목으로 결합합니다. 회귀 테스트 중에 걸음 수 피팅을 적용하여 노이즈를 줄일 수 있습니다.
이렇게 하면 단일 빌드의 벤치마크 시간이 느려졌다가 다시 정규화될 때 발생할 수 있는 거짓양성 발생을 줄일 수 있습니다.
테스트 범위 회귀 검사
테스트 적용 범위는 사용자 및 사용자의 팀이 테스트에 변경사항을 충분히 포함하는지 판단하는 데 도움이 되는 측정항목입니다. 그러나 이것이 유일한 지표가 되어서는 안 됩니다. 일반적으로 커버리지가 기본 브랜치를 기준으로 하향 조정될 때 실패하거나 경고를 표시하는 회귀 검사를 설정하는 것이 일반적입니다.