테스트 코드, 안드로이드에서는 어떻게 작성해야 할까?

Context

뱅크샐러드는 빠른 배포 주기로 인해 테스트 코드 부재 영역에서 장애가 발생하고 핫픽스를 반복하는 상황을 경험했다. 개발자마다 테스트 코드 작성 범위에 대한 기준이 명확하지 않아 일관성 있는 품질 관리가 어려웠다.

Technical Solution

• 수정/변경되는 모든 기능에 대해 필수적으로 테스트 코드 작성: 새로운 파일 추가, 기존 파일에 동작 추가, 기존 동작 변경 시 한 줄 수정이라도 테스트 코드 작성
• Presenter의 Presenting Logic에 대한 Unit Test 필수화: Mockito를 사용해 View 인터페이스를 mocking하고 verify()로 뷰 함수 호출 검증
• 뷰 함수 호출 순서 검증: Mockito.inOrder()를 통해 Presenting Logic의 순차적 실행 검증
• 뷰 함수 미호출/중복 호출 검증: Mockito.never()와 Mockito.times()로 호출 횟수 제어
• View에 Presenting Logic이 포함된 경우 2가지 대응: Instrumented Test 작성 또는 로직을 Presenter로 분리 후 Unit Test 작성
• RecyclerView ViewHolder 등 android 패키지 의존도가 있는 영역: Instrumented Test로 LayoutInflater를 통해 실제 View 인스턴스 생성 후 테스트
• View 로직에 포함된 비즈니스 로직을 Presenter로 추출: 예시로 SaladViewHolder의 bind() 로직을 SaladBowlPresenter의 onBindSalad()로 이동하여 Unit Test 가능하게 리팩토링

Impact

아티클에 정량적 수치(성능 향상 %, 장애 감소율, 커버리지 목표치 등)가 명시되어 있지 않음.

Key Takeaway

MVP 또는 Clean Architecture를 사용하는 모바일 팀에서 View와 Presenter를 명확히 분리하고 Presenter 단위 테스트를 필수화하면, 테스트 가능한 코드가 자동으로 관심사 분리가 잘된 구조를 갖추게 되어 유지보수성과 안정성이 동시에 향상된다.