[Test-Concept] 테스트 피라미드

테스트 피라미드라는 개념은 애플에서 제시한 아이디어 인 줄 알았는데,
안드로이드 테스트 세미나(이름: 안드로이드 탐구영역)를 듣고 와서 두루 쓰이는 개념이라는 것을 알게 되었습니다

그래서 덧붙여서 다시 정리...!! 

 

테스트 피라미드는 이렇게 생긴 것 입니다

 

세미나에서 우섭님(뱅.샐)이 테스트 피라미드를 이런 그림으로 정리해주셨는데요,

y축부터 봅시다..! 위로 올라갈 수록 실제로 돌아가는, 유저가 쓰는 영역이라 믿을 만한 영역입니다. 하지만 실행시간이 오래 걸리고 유지보수, 디버깅 하기 더욱 어려운 영역입니다. 

그 다음 x축을 봐봅시다..! 밑으로 내려 올 수록 더 많은 테스트 코드를 작성하게 됩니다

 

 

이런 피라미드 접근법은 어떤 유익이 있을 까요?!

애플에 의하면, 피라미드 모델 접근법은 철저성(thoroughness), 품질(quality), 실행 속도(execution speed) 사이의 균형을 잡는 데 도움이 된다고 합니다. 그리고 이 피라미드는 세 가지 다른 테스트 유형 간의 균형을 유지하는 것도 도와준다고 합니다. 

 

그럼 각 단계를 하나씩 살펴봅시다...!!!! 

 

1. Unit Test 

피라미드의 기초는 Unit Test입니다. 단위 테스트는 함수같이 a single piece of code를 검증하는 데 도움을 줍니다.

함수에 인풋을 넣고 기대했던 아웃풋이 나오는 지 확인하는 식입니다. 단위 테스트는 짧고 간단하며 매우 빨리 실행된다는 특징을 가집니다. 

 

 

2. Integration Test

그 다음 통합테스트입니다. 통합 테스트는 코드의 더 큰 부분을 검증하는 데 사용됩니다. 

이러한 테스트는 구체적인 하위시스템이나 클래스의 모음을 타겟으로 하는데, 서로 다른 구성 요소가 함께 올바르게 동작하는지 확인하기 위해서 합니다. 통합 테스트는 피라미드에서 유닛테스트 위에 위치하는데, 큰 코드 조각을 테스트하기 전에 개별 기능이 올바르게 작동하는지 확인하고자 하기 때문입니다. 
일반적으로 단위 테스트만큼 많은 통합 테스트가 필요하지 않을 것입니다. 통합 테스트는 실행하는데 약간 더 오래 걸릴 수 있지만 한번에 더 많은 앱을 테스트할 수 있습니다. 

 

 

유닛테스트만 하고 통합테스트만 했을 때 어떤 상황이 일어날 수 있는지 우섭님께서 비유로 든 사진입니다 

 

각각의 모듈은 잘 동작할 수 있지만 (즉 각각의 문은 잘 열리지만) , 위의 사진 처럼 같이 썼을때 문을 열기 메롱해질 수 있습니다...!!  

그래서 각각을 테스트 했음에도 불구하고 각각을 모아둔 것을 또 테스트해야할 필요성이 있는 것입니다

 

3. UI Test

마지막으로 UI테스트입니다. 

UI 또는 사용자 인터페이스 테스트는 앱의 사용자 단계 동작을 관찰합니다. 이것은 당신의 앱이 당신이 기대하는 것을 확실히 하도록 만듭니다.

UI 테스트는 실행하는 데 가장 오래 걸리지만 모든 것이 올바르게 작동함을 입증하는 데 필수적입니다. 
하지만 UI 테스트는 앱의 UI가 더 자주 변경될 수 있기 때문에 더 많은 유지보수가 필요합니다.(ㅠㅠ)

 

 

간단히 정리하면 다음과 같습니다..! 

 

 

이제 예제를 살펴봅시다

1. 간단 예제

덧셈을 하는 앱을 만든다고 해봅시다 

먼저 Unit Test를 작성합니다. 내가 만든 덧셈함수가 제대로 된 output을 내는지 테스트해보는 것이 Unit Test 입니다. 

 

 

그 다음 통합테스트를 작성합니다. 

 

덧셈과 히스토리 관련 내용도 같이 테스트해보기 때문에 통합테스트입니다...! (저 히스토리가 정확히 무엇을 말하는 건지 필기도 안되어 있고 피피티에도 코드가 저거 밖에 없네용.....흑)

 

그 다음 UI Test입니다 

 

앞에서는 숫자를 직접 코딩으로 넘겨줘서 테스트했다면 사용자가 계산기에서 숫자를 누르는 행동까지 테스트 합니다.

사용자가 계산기 뷰에서 1+1을 타이핑하고 submit버튼을 눌렀을 때, resultText로 2가 보이는지 테스트하는 것입니다. 

 

2. 좀 더 복잡한 예제

이번엔 네트워킹하는 앱에서 어떻게 세 단계로 테스트할 수 있는 지 봅시다

이렇게 동작하는 앱이 있다고 합시다

 

 

 

파라미터의 맨 밑부분인 Unit Test부터 해봅시다 

 

 

URLRequest를 준비하는 함수, response를 parse 하는 함수를 각각 테스트합니다

두 함수는 이렇게 생겼습니다

 

 

첫번째, makeRequest함수를 테스트합니다. 우리가 원하는 request를 잘만들어주는 지 테스트해봅시다.

 

 

두번째,  parseResponse함수를 테스트합니다. 더미 JSON 데이터를 아래 처럼 만들고 이 함수가 파싱을 잘해주는 지 테스트해봅시다.

 

 

그 다음 이 부분에 해당하는 함수를 살펴봅시다.

 

loadAPIRequest 함수에 우리가 아까 테스트했던 makeRequest함수와 parseResponse함수가 들어가게 됩니다.

이것을 테스트하는 것은 통합테스트라고 볼 수 있습니다. 위에서 말한 것 처럼 개별기능의 동작을 먼저 확인하고 더 큰 코드조각을 테스트하는 것이죠.

 

 

그리고 이렇게 APILoaderTest에서 쓸 MockURLProtocol을 만들어봅시다. 

 

( MockURLProtocol 만드는 과정은 http://minsone.github.io/ios/mac/ios-mock-network-request 여기서 보세요 설명 굿..!! )

 

이런식으로 통합테스트를 작성해줍니다

 

 

 

마지막으로 테스트 피라미드의 꼭대기인 UITest를 작성해봅시다 

 

 

자세한건 2015 WWDC 영상을 보라고 하네요

 

 

엔드 투 엔드 테스트를 쓰기 시작할 때 마주치는 중요한 도전은, 테스트가 실패했을 때문제의 근원을 어디서 찾기 시작해야 할지 아는 것이 정말 어려울 수 있다는 것이라고 하네요. 이를 완화하기 위해 우리가 방금한 것 처럼 실서버 대신 Mock 서버를 이용하는 것이 좋습니다.

 

 

이것은 우리의 UI 테스트가 훨씬 더 신뢰할 수 있게 해줍니다. 왜냐하면 우리는 앱으로 다시 공급되는 데이터를 통제할 수 있었기 때문이죠.

쉽게 말하면!! Mock서버를 써서 여러 실패원인을 차단하고 딱 UI만 테스트할 수 있게 하자고 하는 것 입니다.

하지만 "이러한 맥락에서 모의 서버를 사용하는 것이 정말로 유용할 수 있지만, 실제 서버에 요청을 하는 몇 가지 테스트를 직성하는 것도 좋다. " 라고 덧붙이시긴 했습니다. 

 

 

Reference

WWDC 2018 - testing tips & tricks 

WWDC 2019 - Testing in XCODE

GDG 안드로이드 코리아 [안드로이드 탐구영역] - 아장아장 테스트 첫걸음 (뱅크샐러드 김우섭님)