Ch1. TDD란 무엇인가?

Why use TDD?

TDD는 소프트웨어가 잘 작동하고, 미래에도 계속 잘 작동 할 것을 보장해준다.

• 코드를 전부 작성한 뒤, 테스트 코드를 작성할 수도 있다.
• Alternatively, you could skip writing tests altogether and, instead, manually test your code

하지만 TDD가 이런 방법에 비해 갖는 장점은?

<좋은 테스트>는 앱이 기대하는 바와 같이 동작하는 것을 보장한다.

모든 테스트가 <좋은 테스트>는 아니다.

<좋은 테스트>는 failable, repeatable, quick to run and maintainable 해야 한다.

TDD는 아래와 같은 방법론을 통해 좋은 테스트 작성을 보장한다.

• 첫 번째는 failing test를 작성하는 것이다. 말 그대로, 이 과정은 테스트가 failable하다는 것을 보장할 수 있다. 실패하지 않는 테스트는 유용하지 않다. 그저 CPU타임을 잡아먹기만 할뿐
• 새로운 테스트를 작성하기 전에, 이전의 모든 테스트는 통과해야 한다. 이는 여러분의 테스트가 repeatable하다는 것을 보장한다: 작업 중인 하나의 테스트만 수행하는 것이 아니라 항상 전체 테스트를 수행해야 한다.
• 테스트를 자주 수행함으로써, 테스트가 Quick to run한지를 체크해주자. 모든 테스트를 수행하는데 1초 이하의 시간이 걸리는게 좋다. 하나의 테스트가 a hundered milliseonds가 걸린다면 이는 너무 느린 것이다. 10개의 테스트만 수행해도 몇 초가 걸리게 될 것이며, 50개의 테스트를 수행하면 5초가 걸린다. 이렇게 느리면 아무도 이 테스트를 수행하고 싶지 않을 것이다.
• Refactor할 때, 프로덕션 코드와 테스트 코드 모두를 변경한다. 테스트가 maintained함을 보장한다. 항상 up-to-date 상태의 테스트를 유지하자.
• 프로덕션 코드와 테스트 코드를 같이 작성함으로써, 작성한 코드가 testable함을 보장할 수 있다. If you were to write tests after completing the code, it’s likely the production code would require quite a bit of refactoring to fully unit test.

무엇을 테스트해야 하는가?

높은 테스트 커버리지가 잘 테스트 되었음을 의미하지는 않는다. 테스트 해야하는 것과 그렇지 않은 것들이 있다.

• Do write tests for code that can’t be caught in an automated fashion otherwise
• Generated code에 대한 테스트를 작성하지 마라. 예를 들어, generated getters, setters코드를 테스트할 필요는 없다. 스위프트가 알아서 잘 하니까 믿어라
• 컴파일러가 캐치할 수 있는 테스트코드는 작성하지 마라
• First-party, Third-party와 같이 의존성을 갖는 코드는 테스트를 작성하지 마라. 이 프레임워크 개발자가 테스트 코드를 작성할 책임이 있다. 너희는 없다. 예를 들어, UIKit의 테스트를 작성할 필요가 없다. 하지만 이를 서브클래싱하는 커스텀 코드에 대한 테스트는 작성해야 한다.

예외가 있다. 프레임 워크가 작동하는 방식을 결정하기 위해 테스트를 작성하는 것이다. 길게 가져갈 필요는 없다. 바로 삭제해주자.

또 하나의 예외가 있다. 서드 파티 코드가 기대한대로 작동하는지 확인하기 위한 "Sanity tests". 라이브러리가 안정적이지 않고, 믿기 힘들다면 이러한 테스트는 유용하다. 아니면 그냥 그 라이브러리를 다 까보는 방법도 있다(scrutinize).

TDD는 너무 오래걸려요!

TDD에 대한 공통의 불만은 너무 오래 걸린다는 것이다. 하지만 익숙해지면 빨리 할 수 있다. 테스트를 작성하지 않으면 더 많은 코드를 작성할 수 있긴 하다(당연한 소리).

이 주장에는 구멍이 있다. 실제 개발 비용은 first-version 프로덕션 코드를 작성하는 것만을 의미하는 것이 아니다. 새로운 피쳐가 추가되기도 하고, 코드를 수정해야할 일이 생기기도 한다. 버그를 수정하는 것도 있을거고. 길게 봤을 때, TDD를 따르면 maintaiable코드를 작성하게 될 것이고, 버그도 줄어들게 된다.

또 생각해봐야 할 것은 customer impact of bugs in production이다. 버그를 늦게 발견할 수록 더 많은 비용이 필요하다. 고객에게 신뢰를 잃거나 부정적인 리뷰를 받게 될 것이다.

이슈가 개발도중 잡힌다면 디버깅도 쉽고 고치기도 쉬울 것이다. TDD를 따름으로써, 테스트는 궁극적으로 앱을 버그로부터 지키는 것을 돕게 될 것이다.

TDD는 언제 쓰면 될까?

어떤 개발 상황에도 사용가능하다. 새 프로젝트, 레거시 앱 무엇이든 가능하다. 하지만, 어떻게 어디서부터 TDD를 적용할지는 프로젝트의 상황에 따라 다르다. 이 책에서는 이렇게 다양한 상황에 대해 다룰 것이다.

장기적으로 운영할 계획의 앱은 TDD를 쓰는 것이 좋다. 그렇지 않다면, 예를 들어 해커톤처럼 임시 프로젝트인 경우, TDD가 가치 있는지에 대해 고민해볼만 하다. TDD를 적용하지 않거나 부분적용만하는게 나을 수 있기 때문이다.

Key points

In this chapter, you learned what TDD is, why you should use it, what to test and when to use it. Here are the key points to remember:

• TDD offers a consistent method to write good tests.
• Goods tests are failable, repeatable, quick to run and maintainable.
• Write tests for code that you’re responsible for maintaining. Don’t test code that’s automatically generated or code within dependencies.
• The real cost of development includes initial coding time, adding new features over time, modifying existing code, fixing bugs and more. TDD reduces maintenance costs and quantity of bugs, often making it the most cost effective approach.
• TDD is most useful for long-term projects lasting more than a few months or having multiple releases.