여전히 많은 iOS 개발팀이 Unit Test를 작성하지 않는다.
Unit Test가 없더라도 QA직군이 없더라도 개발자라도 모여서 수동으로 테스트를 한다.
자동화 테스트를 원활히 하기 위해서는 반드시 아키텍처 전반에 걸쳐서 기반을 다지는 작업이 선행되어야 한다.(1부, 2부에서 했던 작업과 같이)
애플의 Vanilla MVC 기반의 아키텍처에서는 Unit Test를 작성하기가 매우 까다롭다.
테스트가 어렵다면 우선 아키텍처가 좋지 않을 가능성이 크다.
테스트 가능한 코드는 기본적으로 의존성에 대한 고민이 녹아있어서 의존성 주입 패턴이 들어가 있다. 또한 Unit Test를 만들다보면 내가 만든 코드를 사용하는 개발자의 입장에서 써보기 때문에 더 직관적으로 개발하게 된다.
테스트는 여유가 있을 때 하는게 아니라 여유가 없을 때 오히려 해야한다.
테스트 작성에 실패하는 대부분의 이유는 이미 구현한 코드가 Testable한 코드가 아니기 때문이고, 도입한다해도 어떻게 고쳐야할지 모르기 때문이다.
레거시 코드에서 테스트를 새로 도입하려면 기반작업을 해야하고 곧바로 성과가 보이지 않아서 힘들 수 있다.
테스트의 종류와 종류별로 얼마만큼의 테스트를 작성해야하는지 가이드를 주는 개념
피라미드의 아래쪽일 수록 테스트 환경은 더 고립되고 테스트 실행속도는 더 빨라진다.
위로갈수록 테스트하는 객체나 모듈의 갯수가 많아지고 테스트 실행속도는 느려진다.
피라미드 안에 있는 각 테스트의 사다리꼴 모양/삼각형 모양의 면적이 의미하는 것은 테스트 케이스의 갯수와 비율을 뜻한다.