TDD
Updated:
TDD
- 테스트 주도 개발(Test-Driven Development) 은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나 이다. 개발자는 요구되는 기능에 대한 자동화된 테스트 케이스를 작성하고, 해당 테스트를 통과하는 가장 간단한 코드를 작성한다. 일단 테스트 통과용 코드를 작성 후 상황에 따라 Refactoring 과정을 거치는 것이다. - 이미지출처
말 그대로 Test 가 코드 작성을 주도하는 개발방식이다.
- 코딩을 다 짜고 난 후 테스트를 하는 것이 아니라 그때 그때 테스트를 하는 것, 새로운 기능을 추가 하면 기존에 잘 작동하던 기능들이 안되는 경우가 발생하고, 개발자가 이 부분을 인식하지 못할 때가 발생 할 수 있다. 이러한 경우를 방지 하기 위해 테스트 코드를 작성하는 것이다.
즉 기존에 기능을 잘 작동하는지와 동시에 새로운 기능이 제대로 작동하는지를 테스트를 통해 확인 하는 것.
- TDD는 언제 해야하는가
- 불확실성이 높을 때 - 해당 코드가 제대로 작동하는지 의문이 들거나, 처음 작성하는 부분일 경우
- 개발하는 중에 코드를 많이 바꿔야 하는 경우 - 기능이 많이 들어간 함수를 세부적으로 나누거나 하는 경우
- TDD의 효과
- FeedBack의 증가 - 테스트를 통과함으로 인해 기능들이 잘 되는가를 자주 확인 가능.
- 협력 - 개발의 대부분은 혼자가 아니라 2인이상의 다수에 의해서 진행된다. 테스트를 하고, 테스트 코드를 같이 보면 구현자가 구현하고자 한 것들이 좀 더 명확 하게 보이고, 다른 사람들은 왜 그렇게 코드를 구현 했는지 쉽게 알 수 있기 때문에 협력적 측면에 좋다.
- TDD에 대한 장/단점 & 의문점
- 개발 시간의 증가 - test를 진행해야 하므로 개발 시간은 증가 할 수 있다.
- 버그 감소 - 발생 할 수 있는 여러 버그들을 test를 진행하며 그때 그때 고쳐 나갈 수 있기에 버그를 줄일 수 있다.
- 테스트 코드 ? - 어떻게, 어떤 부분을 테스트 할지는 학습이 필요하고, 시간이 필요하다. 개발은 혼자가아닌 여럿이 하는 것 이기에 팀 전체가 익숙해야 한다.
- 모든상황에서 테스트가 가능한가 ? - 모든 코드에서 테스트 코드를 작성 할 수 없으며, 그럴 필요가 없다고한다. 테스트 코드를 작성한다고 해서 버그가 완전히 사라지는 것이 아니다. 애초에 TDD는 100% coverage, 무결성을 주장하지 않는다.
- TDD에 대한 논쟁 - (2014년?)
- TDD에 관하여 완벽하게 이해하고 있지는 못하지만, 여러가지 논쟁이 있기에 첨부한다.
- “TDD는 죽었다” - Ralis를 만든 DHH의 글
- TDD는 죽었는가?
- TDD는 죽었다…? - 왜 논쟁이 벌어지고 여러가지 말이 나오는지는 이 블로그를 보면 잘 되어있는거 같다.