TDD를 포기하는 이유와 그럼에도 해야하는 이유

• TDD가 뭔지?
• 겪을 수 있는 어려움은 무엇이 있는지?
• 어려움을 해결하는 방법은 무엇이 있는지?
• 무엇을 테스트해야 하는지?
• TDD를 함으로써 얻을 수 있는 장점이 뭔지?

TDD(Test Driven Development)란?

TDD란 각 요구사항에 대해 다음과 같은 과정을 거쳐 기능을 구현해 나가는 개발 방식을 말한다.

1. 먼저 요구사항에 대하여 실패하는 Test를 작성한다. -> 실행하면 당연히 fail
2. Test를 통과시키기 위한 최소한의 코드 작성한다. (멋지게 짜는 게 아니라 겨우 통과만 할 수 있게)
3. 통과한 Test 코드를 개선하며 코드의 퀄리티를 높인다.!

TDD를 포기하는 이유 : 빌드 시간이 너무 많이 걸려요.

TDD는 빌드를 최소 3배 더 함

TDD 방식으로 개발을 하면 실패단계에서 한번, 최소성공 단계에서 한번, 개선 단계에서 한번 최소 3배가 넘는 빌드가 필요하다.
-> 이론상 3배이지만 당연히 각 단계에서 시행착오를 겪기 때문에 보통 10배 이상의 빌드를 하게 된다.

IOS 개발 시 Swift는 컴파일 타임에 에러 체크를 해주는 것이 많다.
런타임이전 단계에서 에러를 사전에 잡아주는 것은 당연히 환영할 일이 지만
내가 고려하지 않았다면 누군가는 연산을 따로 한다는 의미이다.
따라서 IOS 플랫폼은 다른 플랫폼들에 비해 빌드시간이 오래 걸린다.

빌드를 더 많이 하는 특성상 TDD가 가능하기 위해서는 기본적으로 빌드시간이 매우 짧아 져야한다.

빌드 시간을 줄이면 얻는 효과

• 인건비 절약 : 잦은 빌드를 통해 낭비되는 개발 리소스를 다른 곳에 사용할 수 있다.
• 더 빠른 릴리즈 : 단순 직관에 의해서 A안 B안 중 선택해야하는 상황에서 빌드시간이 빠르면 일단 둘다 만들어보고 실험을 통해 좀더 합리적인 선택의 근거를 얻을 수 있게 된다.
• 모듈화 : 빌드시간을 줄이기 위해서는 필연적으로 모듈화가 필요하게 된다. 모듈화를 이용하면 아키텍쳐를 좀더 튼튼하게 가져갈 수 있다.

빌드 시간 줄이는 방법

1. 빌드를 병렬화 한다. : 의존성을 끓어내서 직렬로 수행되던 빌드를 다중 코어를 이용하여 병렬로 만든다.
   • private을 기본 접근 제한자로 사용해서 의존 가능성의 범위를 제한한다.
   • 모듈화하고 모듈 사이의 의존성을 최소화한다.
2. 빌드할 코드 자체를 줄인다 : 써드 파티 라이브러리 같은 외부에서 가져온 코드들은 미리 빌드해놓고 계속사용한다.
   • 미리빌드 : Carthage, Cocoapods Binary Cache, xcframework
3. 모듈만 빌드를 진행한다. : 전체 빌드가 아닌 모듈별로 빌드를 실행한다.
   • 빌드시간을 줄이기 위해서는 빌드의 현재 상황에 대해서 파악해야 하는데 Xcode 14부터 Editor -> Open timeline에서 현재 모듈간의 의존성, 빌드 순서, 병렬화 여부등을 파악할 수 있다.

그럼 뭘 테스트 하지?

테스트라고 하면 내가 작성한 코드에 입력을 넣었을 때 기대한 출력이 나오는지를 확인하는 작업이다.

근데 실전에 가면 무엇을 테스트 해야할지 난감하다.

• 코드에 입력이 뭐고 출력이 뭔지를 알지 못하는 경우.
• 출력에 대해서 어떤 것을 검증해야할지 감이 안 잡히는 경우.
• 테스트 코드가 구현 코드랑 거의 유사한 경우. -> 굳이 이짓을 두번해?

요구사항을 테스트 해라.

• 모든 요구사항은 테스트 케이스다.
• 고객이 무언가를 요구하고 이 요구사항에 대한 제품을 만들었을 때 고객이 요구 사항이 잘 구현된 제품이 맞는지를 확인하는 것이 테스트다.

아래와 같이 화면에 대한 요구사항이 주어졌을 때 모든 요구사항에 대한 테스트 코드를 작성한다.

요구사항을 3요소로 분석한다.

• Given : 어떠한 상황이 주어지고 ex) 처음 로그인한 유저가
• When : 이 상황에서 어떤 액션을 했을 때 ex) 화면에 처음 진입했을 때
• Then : 액션에 대한 결과값으로 무었이 나와야하는가? ex) ‘안녕’이라고 적힌 토스트가 뜹니다.

고객의 요구사항을 테스트해라.

• 고객은 ViewDidLoad에 어떤 코드가 들어가는지에 대해서는 관심이 없다.
• 고객의 요구사항 대부분은 특정 플랫폼, 프레임워크와는 상관이 없다.
• 고객의 요구사항을 표현한 코드는, 안드로이드, 웹에서도 대부분 재활용 가능해야한다.

접근성 경험

가장 중요한 것은 고객이 원하는 데이터를 잘 가공해서 알기 쉬운 형태의 정보로 만들어 전달하느냐 이다.

• 주어진 정보를 유저가 이해하기 쉬운 구조로 표현하는 것은 클라이언트 로직의 핵심이고 대부분이다.
• 눈에 보이지 않는 스펙일 수록 놓치기가 쉽기 때문에 자동화로 챙겨야한다.
• 접근성 경험이 튼실하면 UI 테스트도 쉬워진다.

TDD의 과실

• 모든 동료로부터 좋은 피드백을 받기 쉬워진다.
  • 디자인 시안에 숨겨져 있는 케이스들은 테스트를 만드는 과정에서 명확해진다.
  • 따라서 테스트를 만드는 과정에서 해결해야하는 것이 명확해지면 기획자, 디자이너, 다른 플렛폼 개발자들과도 피드백을 나누는 것이 수월해진다.
  • 코드 리뷰가 수월해진다. ( 구현해야하는 것들이 명확히 케이스별로 쪼개져 있기 때문에 코드를 리뷰해주는 사람 입장에서도 코드 작성자의 의도를 쉽게 이해할 수 있다.)
  • 질 좋은 피드백은 조직원의 성장 한계치를 높인다.
• 개발을 빠르게 할 수 있다.
  • “앱을 켜서 로그인을 하고 또 뭐 화면을 넘겨서 아래 버튼을 누르고”를 직접하면서 코드가 지금 맞게 돌아가고 있는지 확인하지 않아도 된다.
  • TDD를 하지 않았다면 발견하지 못했을 버그들을 미리 발견함으로써 향후 발생할 문제를 예방할 수 있다.