[Android] 테스트 코드는 왜 작성해야 할까?

 

 

 

안드로이드에서 "왜" 테스트 코드를 작성해야 할까?

 

지금까지 테스트 코드에 대해 알아보기 전에는 '대체 왜 테스트 코드를 작성해야 하는가' 에 대해 의문을 품고 있었습니다.

필자뿐만 아니라 이 글을 읽는 많은 분들이 그렇게 생각하셨을 것입니다.

우선 테스트 코드를 작성하지 않았을 때의 개발 flow에 대해 정리해보았습니다.

 

기존 개발 Flow

• 기획물과 디자인 작업물을 바탕으로 코드를 작성하여 기능을 구현합니다.
• 구현한 기능이 정상적으로 작동하는지 AVD 또는 실제 디바이스를 바탕으로 결과를 확인합니다.
• 에러가 발생하면 Timber 또는 Log를 통해 어느 부분에서 오류가 발생했는지 파악합니다.
• 문제가 있는 코드를 fix하고 다시 빌드하여 위 과정을 반복합니다.

 

위 flow를 읽어보았다면 이런 생각이 들 것입니다.

'어? 나도 저렇게 해왔는데..?'

'이렇게 해도 오류를 찾고 수정할 수만 있으면 되는거 아닌가?'

 

하지만 이러한 flow는 단기 프로젝트나 사이드 / 소규모 프로젝트에서 적용되는 이야기입니다.

프로젝트의 규모가 커질수록 어느 순간부터는 조금만 규모가 커져도 매우 복잡해지기 마련입니다.

 

앱의 규모가 커진다면 어떤 문제가 발생할까요?

• 빌드 시간 증가
• 프로젝트 자체의 복잡성 증가
• 화면(UI)에 값을 직접 입력하고 결과 확인 시간 증가

 

프로젝트 규모의 증가에 따라 검수 시간도 마찬가지로 증가하게 됩니다.

즉, 하나의 화면을 테스트하기 위해 매번 앱 전체를 빌드하거나 레이아웃에 값을 입력하는 것 자체가 비효율을 초래한다는 것을 의미합니다.

뿐만 아니라 실제 현업에서는 프로젝트를 진행할 때 마감 시간을 엄수해야 합니다.

따라서 우리는 앱의 규모가 작던 크던 로직이 개발자의 의도대로 작동하는지 검증하고 생산성을 높이기 위해 반드시 작성해야할 필요가 있다고 생각합니다.

 

테스트 코드 작성시 이점

그렇다면 테스트 코드를 작성했을 때 어떤 이점이 있을지 생각해보겠습니다.

• 앱의 규모가 커져도 부분적으로 검증 가능
• 디버깅 시간 단축
• 모듈이 의도대로 동작하는지 확인 가능
• 직접 화면에 값을 입력하는 수고를 덜 수 있음
• 잘못된 코드 영역을 빠르게 확인할 수 있음 (전체 코드 중에서 찾을 필요가 없기 때문에)

 

Test in Android

 

Android에서 테스트는 크게 Unit Test(단위 테스트) / Instumentation Test(계측 테스트)  2가지 영역으로 나뉩니다.

 

Unit Test

• app(module)/src/test/java/ 하위에 테스트 코드를 작성
• JVM에서 실행되는 로직 테스트
• Instrumentation Test에 비해 속도가 빠름
• Android 프레임워크에 종속성이 없는(단순 class, method) 모의 객체(Mock)을 생성할 수 있는 테스트 가능
• 주요 라이브러리 : JUnit, Mockito, PowerMock, Truth, Robolectric

 

 

Instrumentation Test

• app(module)/src/androidTest/java 하위에 테스트 코드 작성
• Android 프레임워크에 종속성이 있는 코드를 테스트
• 실제 안드로이드 디바이스와 AVD에서 실행되는 코드
• Unit Test에 비해 속도가 느림
• 주요 라이브러리 : Espresso, Robotium, UIAnimator, Appium, Calabash

 

 

3가지 'com' 패키지 중에 맨 위에는 실제로 디바이스에서 동작할 코드를 작성하는 경로입니다.

그 아래 'androidTest' 는 위에서 언급한 Instrumentation Test 를 작성하는 경로입니다.

(구분하기 쉽게 괄호를 통해 안드로이드 테스트를 하는 영역이라고 언급해주고 있습니다.)

마지막으로, 맨 아래는 Unit Test를 하는 경로입니다.

 

테스트 코드 작성 범위

마지막으로 무엇을 테스트해야 하는지에 대해 알아보고 포스팅을 마무리하겠습니다.

• 수정/변경되는 모든 기능에 대해 반드시 테스트 코드를 작성
• 비즈니스 로직(MVP의 Presenter, MVVM의 ViewModel)에 대한 검증은 필수적이며, View에 대한 테스트 코드를 반드시 작성할 필요는 없음
• 뷰와 로직이 섞여 있는 경우 모듈 간 결합도가 낮아지도록 DI, 디자인 패턴, 클린 아키텍처 등을 적용하여 테스트가 쉽게 이루어질 수 있도록 코드를 작성
• 만약 View에 어쩔 수 없이 로직이 들어가는 경우에는 이하 방법 중 하나로 테스트 코드를 작성
  • Unit test 대신, Instrumented test code를 작성
  • View로부터 Presenter 또는 ViewModel layer로 로직을 분리하는 리팩토링을 거치고, 이에 대해 비즈니스 로직 테스트 코드를 작성

 

 

 

👍클릭으로 구독하기👍

 

(이해가 다소 힘들거나, 틀린 부분이 있다면 댓글 부탁드리겠습니다! 😊)

💖도움이 되셨다면 '구독'과 '공감' 부탁드립니다!💖