[iOS] Unit Test - 단위 테스트 어떻게 하는건데.. (1)

🙈 서론

여러 세션이나 채용공고를 보면 단위 테스트에 대한 이야기를 많이 접할 수 있다.

테스트하며 코딩을 하면 유지보수가 용이하고 코드 안정성을 높이는 등 다양한 장점이 있다.

여태 테스트의 중요성에 대해 잘 알고 있었지만, 내 프로젝트에는 적용해보진 못했다. 그래서 한번 자세하게 파보고자 정리해보려고 한다.

 

 

 

 

 

❓Unit Test에 대해

정의

컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차

즉, 모든 함수와 메소드에 대한 테스트 케이스를 작성하는 절차를 말한다. 이를 통해서 언제라도 코드 변경으로 인해 문제가 발생할 경우, 단시간 내에 이를 파악하고 바로 잡을 수 있도록 해준다. 이상적으로 테스트 케이스는 분리되어야 한다. 이를 위해 가짜 객체(Mock object)를 생성하는 것도 좋은 방법이다. 유닛 테스트는 개발자 뿐만 아니라 보다 더 심도있는 테스트를 위해 테스터에 의해 수행되기도 한다. 

- 위키 백과 - 

하는 이유

• 해당 부분(함수, 메서드)에 대해서 독립적으로 테스트를 하기 때문에 빠른 리팩토링 반영과 빠른 테스트를 진행할 수 있다.
• 코드의 확장이나 리팩토링 시에도 안정성을 확보한 채로 빠르게 대응할 수 있다.

방법

대상 파악

• 핵심 기능 : 모델 클래스 및 메서드 / 컨트롤러와의 상호작용
• 가장 일반적인 UI 워크 플로
• 경계 조건
• 버그 수정

테스트 기준 (FIRST 원칙) 

효과적인 단위 테스트를 위한 간결한 기준 세트

• Fast
  • 테스트가 빠르게 진행되어야 한다.
  • 수많은 테스트 코드를 작성할텐데 한 테스트가 느리게 동작하면 너무 오래걸린다.
• Independent/Isolated
  • 각각의 테스트는 서로 독립적이며 의존해서는 안된다. 
    • 테스트는 서로 상태를 공유해서는 안된다.
  • 의존성이 높으면 테스트의 원인을 찾기 어려워진다.
• Repeatable
  • 테스트를 실행할 때마다 동일한 결과를 얻어야 한다.
  • 통제하기 어려운 부분은 테스트를 위한 객체를 만들어주는 방법도 있다.
  • 외부 데이터 공급자 또는 동시성 문제로 인해 간헐적인 오류가 발생할 수 있다.
• Self-validating
  • 테스트는 완전 자동화되어야 한다.
  • 출력은 로그파일에 대한 프로그래머의 해석에 의존하지 않고 “pass” 또는 “fail’ 여야 한다.
• Timely
  • 이상적으로는 테스트하는 프로덕션 코드를 작성하기 전에 테스트를 작성해야 한다. 이를 테스트 주도 개발이라고 한다. (TDD)
    • (이게 그 유명한 TDD?…)

 

 

 

🤔 Xcode에서의 UnitTest

프로젝트를 만들 때 보면 이렇게 includes Tests 가 있는데 이걸 체크하고 프로젝트를 생성하면 추가로 Tests 폴더가 더 생긴다.

생성된 것

• (프로젝트 명) + Tests
  • (프로젝트 명) + Tests
• (프로젝트 명) + UITests
  • (프로젝트 명) + UITests
  • (프로젝트 명) + LaunchTests

실행

• Build - cmd + B
• Test - cmd + U

Test를 시작하면 앱이 2개가 설치된다.

처음에는 일반적인 Tests 코드들부터 진행되고 그다음에는 UITests를 진행하는데 이건 시간이 오래 걸린다.

그리고 UITests가 종료되면 다크 모드로 변한다 ㅎㅎ;;

 

 

 

🧠 테스트 코드 작성 요령

First Test 작성 방법

• 테스트 메소드의 이름은 항상 test로 시작하고 그 뒤에 테스트 대상에 대한 설명이 온다.
• given, when, then 섹션으로 나누는 형식이 좋다.
  • given: 필요한 값을 설정한다. 그리고 예상 값이랑 비교할 때 쓰인다.
  • when : 테스트 중인 코드를 실행하는 섹션이다.
  • then : 테스트가 실패하면 인쇄되는 메시지와 함께 예상한 결과를 주장하는 섹션이다.

예제

func testScoreIsComputedWhenGuessIsHigherThanTarget() {
  // given
  let guess = sut.targetValue + 5

  // when
  sut.check(guess: guess)

  // then
  XCTAssertEqual(sut.scoreRound, 95, "Score computed from guess is wrong")
}

 

 

테스트 디버깅

앱의 목적에 버그가 있을 때 그것을 찾는 방법을 알아보자.

중단점 탐색기에서 테스트 실패 중단점을 추가한다.

이렇게 하면 테스트 메서드가 실패를 찾았을 때 테스트 실행이 중지된다.

그러면 디버그 콘솔을 검사했을 때 어떤 값이 문제가 있는지 확인할 수 있다.

 

 

XCTestExpectation을 사용하여 비동기 작업 테스트

모델을 테스트하고 테스트 실패를 디버그 하는 방법을 배웠으므로 이제 비동기 코드 테스트로 넘어갈 차례이다.

URLSession메서드는 비동기식입니다. 즉시 반환되지만 나중까지 실행이 완료되지 않는다.

비동기식 메서드를 테스트하려면 XCTestExpectation를 사용해서 비동기식 작업이 완료될 때까지 테스트를 대기시켜야 한다.

비동기 테스트는 일반적으로 느리므로 더 빠른 단위 테스트와 별도로 유지해야 한다.

XCodeTest Method

1. expectation(description:)
   • XCTestExpectation을 리턴한다.
   • 예상되는 결과 값을 description에 넣는다.
2. promise.fulfill()
   • 비동기 메서드 완료 핸들러의 성공 조건 클로저에서 이것을 호출하여 기대가 충족되었음을 플래그로 지정한다.
3. wait(for:timeout:)
   • 모든 기대가 충족되거나 timeout 되어서 간격이 끝날 때까지 테스트를 계속 실행한다.

 

 

Failing Fast

실패는 아프지만 영원히 걸릴 필요는 없다.

URL을 틀려 일부로 실패하는 테스트 케이스를 만들어서 테스트한다.

그렇다면 전체 시간 초과가 되는 간격이 구해진다. 왜냐하면 항상 성공할 거라고 가정했고, 거기서 promise.fulfill()을 불렀기 때문이다.

request가 실패되었기 때문에 오직 제한시간이 만료되었을 때만 종료가 된다.

가정을 변경하여 이를 개선하고 테스트가 더 빨리 실패하도록 할 수 있다.

request가 성공할 때까지 기다리는 대신 비동기 메서드의 완료 처리기가 호출될 때까지 기다려라..

이는 앱이 서버로부터 응답(OK 또는 오류)을 수신하는 즉시 발생하며, 이는 예상을 충족한다.

그러면 테스트에서 요청이 성공했는지 여부를 확인할 수 있다.

 

 

Failing Conditionally

어떤 상황에서는 테스트를 실행하는 것이 의미가 없다.

 

예를 들어, testValidApiCallGetsHTTPStatusCode200() 네트워크 연결 없이 실행하면 어떻게 될까? 

물론 200 상태 코드를 받지 못하기 때문에 통과해서는 안 된다. 

그러나 아무것도 테스트하지 않았기 때문에 실패하지 않아야 한다.

 

XCTSkipUnless(_:_:)를 사용할 때 네트워크에 연결할 수 없으면 테스트를 건너뛴다.

네트워크 연결을 비활성화하고 테스트를 실행하여 이를 확인해라.

테스트 옆에 있는 여백에 테스트가 통과하거나 실패하지 않았음을 나타내는 새 아이콘이 표시된다.

 

Faking Objects and Interactions

비동기 테스트는 코드가 비동기 API에 대한 올바른 입력을 생성한다는 확신을 준다.

URL 세션에서 입력을 받을 때 코드가 올바르게 작동하는지, 또는 UserDefaults 데이터베이스 또는 iCloud 컨테이너를 올바르게 업데이트하는지 테스트할 수도 있다.

대부분의 앱은 사용자가 제어할 수 없는 시스템 또는 라이브러리 개체와 상호 작용한다. 이러한 개체와 상호 작용하는 테스트는 느리고 반복할 수 없으며 첫 번째 원칙 중 두 가지를 위반할 수 있다. 대신 스텁에서 입력을 받거나 모의 개체를 업데이트하여 상호 작용을 위조할 수 있다. 

코드가 시스템 또는 라이브러리 개체에 종속되어 있는 경우 가짜를 사용한다. 그 부분을 연기할 가짜 객체를 만들고 이 가짜를 당신의 코드에 주입함으로써 이것을 수행해라. John Reid의 Dependency Injection은 이를 위한 몇 가지 방법을 설명한다.

 

 

Faking Input From Stub

이 테스트는 두 가지 작업을 수행한다.

1. 가짜 데이터와 응답을 설정하고 가짜 세션 개체를 만든다. 마지막으로 가짜 세션을 sut의 속성으로 앱에 주입한다.
2. 스텁이 비동기 메서드로 가장하기 때문에 여전히 비동기 테스트로 작성해야 한다. startNewRound(completion:)를 호출하면 targetValue와 stubed 가짜 번호를 비교하여 가짜 데이터를 구문 분석하는지 확인한다.

테스트를 실행합니다. 그것은 실제 네트워크 연결이 없기 때문에 꽤 빨리 성공할 것이다!

 

 

Faking an Update to Mock Object

이전 테스트에서는 스텁을 사용하여 가짜 개체로부터의 입력을 제공했다.

그런 다음 Mock Object를 사용하여 코드가 사용자 기본값을 올바르게 업데이트하는지 테스트한다.

 

 

UI Testing in Xcode

UI 테스트를 통해 사용자 인터페이스와의 상호 작용을 테스트할 수 있다.

UI 테스트는 쿼리로 앱의 UI 개체를 찾고 이벤트를 합성한 다음 해당 개체에 이벤트를 보내는 방식으로 작동한다.

API를 사용하면 UI 개체의 속성 및 상태를 검사하여 예상 상태와 비교할 수 있다.

tap() 이렇게 하면 분할된 컨트롤의 각 버튼에 올바른 레이블이 있는지 확인한다. 테스트를 실행하십시오. 모든 어설션이 성공해야 한다.

 

 

Testing Performance

Apple 문서 에서 :

성능 테스트는 평가하려는 코드 블록을 사용하여 10번 실행하여 실행에 대한 평균 실행 시간과 표준 편차를 수집합니다. 이러한 개별 측정값의 평균은 테스트 실행에 대한 값을 형성한 다음 기준선과 비교하여 성공 또는 실패를 평가할 수 있습니다.

성능 테스트를 작성하는 것은 간단하다.

측정하려는 코드를 measure()의 클로저에 배치하기만 하면 된다.
또한 측정할 여러 메트릭을 지정할 수 있다.

• XCTClockMetric
  • 경과 시간을 측정한다.
• XCTCPUMetric
  • CPU 시간, 주기 및 명령 수를 포함한 CPU 활동을 추적한다.
• XCTStorageMetric
  • 테스트한 코드가 스토리지에 쓰는 데이터의 양을 알려준다.
• XCTMemoryMetric
  • 사용된 물리적 메모리의 양을 추적한다.

테스트를 실행한 다음 후행 클로저의 시작 부분 옆에 나타나는 아이콘을 클릭하여 measure() 통계를 확인한다. 

측정항목 옆에 있는 선택한 측정항목을 변경할 수 있다.

 

 

 

🙏🏻 Ref

https://www.raywenderlich.com/21020457-ios-unit-testing-and-ui-testing-tutorial#toc-anchor-011

iOS Unit Testing and UI Testing Tutorial

https://yagom.net/courses/unit-test-작성하기/

Unit Test 작성하기 - 야곰닷넷