Unit Test

Unit Test

• Detect logic failures, UI problems, and performance regressions with XCTest.
• → XCTest를 사용하여 논리 오류, UI 문제 및 성능 회귀를 감지
• 모든 함수와 메소드에 대한 테스트 케이스(Test case)를 작성하는 절차
• 목표 : 프로그램의 각 부분을 고립 시켜서 각각의 부분이 정확하게 동작하는지 확인하는 것

Unit Test 장점

• 다양한 수준의 추상화에서 테스트를 작성하는 기능을 용이하게 한다.
• → 테스트를 한다는 것은 안정성을 보장하는 것, 디버깅 시간을 줄일 수 있다
• →효율적이다, 유지 보수에 유리해지고, 스펙을 문서화할 수도 있고, 더 깔끔한 코드를 작성할 수 있다
• 테스트 케이스는 서로 분리되어야 하기 때문에 가짜 객체(Mock Object)를 생성할 수 도 있다.
• → 각 파트를 따로따로 테스트 가능하게!
• 유닛 테스트를 믿고 리펙토링을 쉽게 할 수 있어 변경이 쉽다.
• 코드의 확장이나 리팩토링 시에도 안정성을 확보한 채로 빠르게 대응할 수 있게 됩니다.
• 상향식(bottom-up) 테스트 방식에서 유용하기 때문에 통합이 편리하다
• → 테스트는 이렇게 예상 값과 결괏값을 비교하는 식으로 진행
• ex) XCTAssertEqual은 값이 같은지를 비교하는 메서드

FIRST 원칙

Fast

• 테스트는 빠르게 동작할 수 있어야 합니다. 테스트 코드는 빠르게 확인하고, 수정하고 반영하는 데에 큰 의미가 있기 때문에 속도가 느린 테스트는 테스트 코드의 의미 중 많은 부분을 잃어버린 것과 같다고 볼 수 있습니다.

Independent/Isolated

• 각각의 테스트는 서로 독립적이며 서로 의존해서는 안 됩니다. 좋은 단위 테스트는 최소한의 단위의 테스트에 집중할 수 있게 각 테스트들이 서로에게 영향을 주어서는 안됩니다.

Repeatable

• 테스트는 언제 어디서나 같은 결과가 반복되어야 합니다. 즉 모든 환경을 통제하여 매번 예상한 결과대로 테스트가 진행되게 해야 합니다. 이를 위해서 통제가 어려운 부분에 대해서는 테스트를 위한 객체를 만들어주는 방법을 선택하기도 합니다.

Self-Validating

• 테스트는 Bool을 이용하여 성공/실패에 대해서 스스로 검증이 가능해야 합니다. 테스트 코드 내부에서 이 테스트가 잘 동작했는지를 판별할 수 있어야 합니다. → 의도된 시나리오가 있어야한다.

Timely

• 이상적인 테스트는 테스트하려는 실제 코드를 구현하기 직전에 구현해야 합니다. 만약 실제 코드를 구현한 후에 테스트 코드를 작성할 경우 테스트하기가 매우 까다롭거나 불가능하도록 설계가 되어있을 지도 모릅니다

Unit Test를 작성할 때의 마음가짐

• 테스트 코드는 애플리케이션 코드만큼 중요합니다.
• 100% 코드 커버리지가 목표가 되어서는 안 됩니다.
• TDBF(Test-Driven Bug Fixing) : 버그를 수정하기 전에 테스트 작성먼저!

 

참고 링크

https://www.avanderlee.com/swift/unit-tests-best-practices/

https://developer.apple.com/documentation/xcode/testing-your-apps-in-xcode