우리의 앱에 테스트를 작성하는 4가지 팁
위 사진은 테스트 설계 피라미드 이다.
unit테스트가 많은 비율을 차지하는 경향이 있다. 각각의 method, class를 테스트하면서 읽기 쉽고, 분명한 failure messages를 만들어내는 특징이 있다.
integration에서는 clusters of classes가 올바로 work together하는지 체크하고, 각각의 실행이 수 초를 안넘는 것을 체크한다.
end-to-end system test에서는 UI test를 하며 실제 유저가 사용하는 것과 비슷한 테스트를 하게 된다.
위 과정은 15줄의 코드로 끝나는데, 각각 unit테스트를 작성할 수 있다.
prepare URLRequest는 다음과 같이 테스트를 작성할 수 있다.
비슷하게 Parse Response는 다음과 같이 mock JSON을 만들어 구현이 가능하다.
주목해야할 점은 XCTest로 try할 때 do catch를 안 해도 된다는 것이다.
다음은 URL Session의 테스트를 보자.
우리가 사용하는 메소드와 클래스 , 프로토콜이다.
여기서 unit test와 integration test를 진행한다.
URL protocol은 이런 방식으로 만들어진다.(이해 힘듬 ....)
이런 방식으로 우리는 MockURLProtocol을 만들 수 있다..
위와 같은 방법으로 우리는 시스템과 잘 integrate되고 있고, 코드가 잘 동작한다는 확신을 얻을 수 있습니다.
마지막으로 end-to-end 테스트에서 UI test가 잘 동작할 것이다.
이제 스튜어트가 나옴 .. 근데 이 분은 말이 더 빠름 ...
이제 Notification test를 알아본다.
Notification은 1대다 통신이고, Notification이 post될 때 앱 전체 또는 앱 프로세스에 여러 수신자에게 전달 될 수 있다.
따라서 의도하지 않은 부작용을 피하기 위해 isolated된 방식으로 Notification을 테스트 하는 것이 중요하다.
요로한 방법으로 Notifications를 isolate할 수 있다.
Noti는 default 인스턴스가 있지만 원하면 얼마든 추가 인스턴스를 만들 수 있고 이는 테스팅에 있어 중요한 역할을 한다.
테스트를 하기 위해 default instance 대신 새 인스턴스를 만들어서 종속성 주입을 한다.
다음 코드는 default Noti를 사용하는 코드이다.
이 코드를 바꿔보겟다.
요거슨 테스트 코드이다.
위 코드를 separated noti 를 쓰게 바꿔보았다.
이후 예제들 넘 빨라서 정리 못하 ㅁ..
Mocking with Protocols 를 요약하자면
다음 예시로는 Timer test 가 있음