Skip to main content

Testing

테스트 가치가 있다고 판단되는 기능이라면 최대 3가지 방식으로 테스트를 진행합니다.

  1. 단위 테스트
  2. UI 테스트
  3. 스냅샷 테스트

단위 테스트​

단위 테스트는 다음과 같은 이유로 진행합니다.

  • 리팩터링은 "기존 결과에 영향을 미치지 않고 코드의 로직을 개선하는 작업"를 뜻합니다. 테스트가 없다면 리팩터링 후에 기존 결과에 영향을 미치지 않았는지 확인하기 위해 구현된 모든 로직들을 검토해야 합니다. 이는 리팩터링마다 생산성 저하를 의미하고 리팩터링을 멀리하게 되는 이유가 됩니다. 하지만 테스트 코드가 있다면 리팩터링 후에 전체 테스트를 실행해 보는 것만으로 기존 결과에 영향을 미치지 않았는지 검토할 수 있습니다.

  • 본인 의외에 다른 사람이 작성한 코드가 내가 생각한 대로 정확히 작동할 것이라고 확신하는 건 쉽지 않습니다. 하지만 테스트 코드가 있다면 해당 테스트가 성공함을 확인함으로써 이 코드가 내가 생각한 대로 작동한다는 걸 확신할 후 있습니다.

  • 테스트를 하지 않는다면 Clean Code의 조건 중 하나인 "testable 한 코드" 조건이 무시됩니다. 그러면 자연스럽게 Clean Code와는 점점 멀어지게 됩니다.

단위 테스트 프레임워크로는 JUnit4와 Kotest를 사용합니다.

UI 테스트​

UI 테스트는 다음과 같은 이유로 진행합니다.

  • 여러 가지 UI 상태의 depth에 직접 도달하면서 테스트를 진행하는 건 시간적으로 매우 비효율적입니다.
  • 유저가 하나의 UI에서 정말 많은 상태를 만들 수 있으므로 최대한 많은 상태에서의 UI 테스트가 권장됩니다.

스냅샷 테스트​

스냅샷 테스트는 다음과 같은 이유로 진행합니다.

  • 캡처한 UI를 이미지로 저장하여 디자이너분께 전달하면 좀 더 정확하게 UI를 검증할 수 있습니다.

  • 의도하지 않은 UI에 변화가 생겼는지를 검사할 수 있습니다. 예를 들어 안드로이드의 디자인 시스템은 기본적으로 머터리얼을 사용합니다. 만약 머터리얼이 업데이트되면서 Checkbox를 그리는 방식이 달라졌다면 머터리얼 Change Note를 보지 않는 이상 알아차리기 쉽지 않습니다. (Checkbox의 사용 비중이 앱 내에서 크지 않다고 가정합니다.) 의도치 않은 Checkbox의 변화를 알아차리기 위해선 직접 Checkbox가 쓰이고 있는 UI에 도달해야 합니다. 하지만 스냅샷 테스트를 이용한다면 Checkbox가 변하기 전의 golden과 비교하여 쉽게 변경을 알아차릴 수 있습니다.

  • 직접 확인하는 UI 테스트의 경우에는 확인하고 싶은 UI를 보기 위해 앱 실행 후 해당 UI가 보여지는 화면까지 매번 클릭하여 들어가야 합니다. 하지만 스냅샷 테스트를 이용한다면 내가 원하는 UI가 캡처된 이미지 파일을 확인하는 것으로 원하는 UI의 결과 확인이 가능합니다. 이렇게 스냅샷 테스트를 진행한다면 많은 UI 테스트의 시간을 줄일 수 있습니다.

  • UI 캡처만 하면 되므로 정말 쉽게 여러 상태의 디자인을 테스트할 수 있습니다. 덕분에 font scale, 다크 모드, 폴더블 디바이스 등등 여러 상태의 UI 테스트를 정말 쉽게 진행하게 됩니다.

스냅샷 테스트 라이브러리는 Roborazzi를 사용합니다.

스냅샷 테스트의 방식으론 크게 3가지가 있습니다.

  1. 피그마 이미지로 골든 테스트
  2. 골든 컴포넌트를 만들어서 골든 테스트
  3. 골든 이미지를 만들어서 골든 테스트

1번의 경우 디자이너분이 가정하신 density 환경과 test-device의 density 환경을 맞추는 게 까다롭습니다.
2번의 경우 골든 컴포넌트를 잘못 설계할 수 있으므로 비교적 정확도가 떨어집니다.
3번의 경우 직접 스냅샷을 확인하여 골든으로 처리하므로 1번과 2번에 비해 높은 정확도를 갖습니다.

따라서 꽥꽥은 스냅샷 테스트를 3번 방식으로 진행합니다.