TDD는 많은 작은 변경을 반복적으로 수행함으로써 소프트웨어를 개발하는 방법이다.
테스트에는 4단계가 있다
•
실패하는 테스트 작성
•
성공
•
리팩터
•
반복
이를 테스트 사이클이라고 한다.
TDD를 쓰면?
•
개발 중에 모든 요구 사항을 충족하는지 확인할 수 있습니다.
•
테스트는 프로덕션 코드의 작동 방식을 설명하는 문서 역할을 합니다.
왜 TDD를 사용해야 하는가?
TDD는 소프트웨어가 작동하고 미래에도 계속 잘 작동하도록 보장할 수 있는 최선의 방법입니다.
TDD는 테스트가 양호한지 확인하는 방법론을 제공합니다.
•
첫 번째 단계는 불합격 테스트를 작성하는 것입니다. 정의상, 이것은 테스트가 실패할 수 있다는 것을 증명한다. 실패할 수 없는 시험은 그다지 유용하지 않다. 오히려 귀중한 CPU 시간을 낭비한다.
•
새 테스트 작성을 허용하기 전에 다른 모든 이전 테스트는 통과해야 합니다. 이렇게 하면 테스트를 반복할 수 있습니다. 작업 중인 단일 테스트만 실행하는 것이 아니라 모든 테스트를 지속적으로 실행합니다.
•
모든 테스트를 자주 실행하면 테스트가 빨리 실행되도록 유도할 수 있습니다. 모든 테스트를 실행하는 데 몇 초 정도 소요됩니다. 가능하면 1초 미만이어야 합니다.
100밀리초가 걸리는 단일 테스트는 너무 느립니다. 10개 테스트만 실행하면 전체 테스트 제품군을 실행하는 데 1초가 걸립니다. 50번의 시험을 거치면 5초가 걸린다. 몇 초 후, 너무 오래 걸려서 아무도 모든 테스트를 실행하지 않습니다.
•
리팩터를 사용하면 프로덕션 코드와 테스트 코드가 모두 업데이트됩니다. 이렇게 하면 테스트가 유지됩니다. 당신은 끊임없이 그것들을 최신 상태로 유지하고 있어요.
•
생산 코드와 테스트를 병렬로 반복적으로 작성하면 코드가 테스트 가능한지 확인할 수 있습니다. 만약 당신이 코드를 완성한 후에 테스트를 작성한다면, 생산 코드는 완전한 유닛 테스트를 위해 꽤 많은 리팩토링이 필요할 것이다.
무엇을 테스트 해야하나?
•
여기에는 클래스의 메소드, 사용자 정의 getter 및 설정자 및 사용자가 직접 작성하는 대부분의 항목이 포함됩니다. 내가 작성한 코드에 대해 테스트를 실시합니다.
•
생성된 코드에 대한 테스트를 작성하지 마십시오. 예를 들어 생성된 getter 및 setter에 대한 테스트를 작성할 가치가 없습니다. 스위프트는 이것을 아주 잘 해내고, 여러분은 그것이 효과가 있다는 것을 믿을 수 있습니다.
•
컴파일러에 걸릴 수 있는 문제에 대해 테스트를 작성하지 마십시오. 테스트된 문제로 인해 오류 또는 경고가 발생할 경우 Xcode가 문제를 해결합니다.
•
앱에서 사용하는 첫 번째 또는 타사 프레임워크와 같은 종속성 코드에 대한 테스트를 작성하지 마십시오. 프레임워크 작성자는 이러한 테스트를 작성할 책임이 있습니다. 예를 들어, 다음에 대한 테스트를 작성하면 안 됩니다. UIKit 때문에 수업은 UIKit 개발자들은 이것들을 쓸 책임이 있다. 그러나 사용자 정의 하위 분류에 대한 테스트는 다음과 같이 작성해야 합니다. 이것은 사용자 지정 코드이므로 테스트 작성 책임이 있습니다.
하지만 TDD는 너무 오래 걸려요!
TDD에 대한 가장 흔한 불평은 그것이 너무 오래 걸린다는 것이다. 보통 느낌표나 슬픈 얼굴의 이모티콘이 뒤따른다.
다행히 TDD는 익숙해지면 속도가 빨라진다. 하지만, 사실은 어떤 테스트도 작성하지 않는 것에 비해, 궁극적으로 더 많은 코드를 작성하고 있다는 것입니다. 초기에 개발하려면 시간이 좀 더 걸릴 것 같다.
그렇기는 하지만, 이 논쟁에는 정말 큰 구멍이 있다. 개발의 실시간 비용은 초기 1버전 생산 코드를 작성하는 것만이 아닙니다. 또한 시간 경과에 따른 새로운 기능 추가, 기존 코드 수정, 버그 수정 등을 포함한다. 장기적으로 보면 TDD를 따르는 것은 버그가 적은 더 많은 유지 관리 가능한 코드를 산출하기 때문에 따르지 않는 것보다 훨씬 적은 시간이 걸린다.
또한 고려해야 할 또 다른 비용도 있습니다. 바로 버그가 생산에 미치는 고객 영향입니다. 미발견으로 넘어가는 이슈가 길어질수록 비용이 많이 든다. 부정적인 평가, 신뢰 상실, 수익 감소를 초래할 수 있다.
개발 중에 문제가 발견되면 디버깅이 쉽고 수정 속도가 빨라집니다. 몇 주 후에 발견한 경우 코드 속도를 높이고 근본 원인을 추적하는 데 훨씬 더 많은 시간을 할애할 수 있습니다. TDD에 따라 테스트를 수행하면 궁극적으로 버그로부터 앱을 보호하고 보호할 수 있습니다.
언제 TDD를 사용해야 합니까?
궁극적으로, TDD는 도구이고 언제 그것을 사용하는 것이 가장 좋은지를 결정하는 것은 여러분에게 달려 있습니다!
TDD는 몇 개월 이상 지속되거나 여러 릴리스가 있는 장기 프로젝트에 가장 유용합니다.
실제 개발 비용에는 초기 코딩 시간, 시간 경과에 따른 새로운 기능 추가, 기존 코드 수정, 버그 수정 등이 포함된다. TDD는 유지 보수 비용과 버그의 양을 줄여주므로 종종 가장 비용 효율적인 접근법이 된다.