개요
TDD로 개발을 하려다 어떤 식으로 Test Code를 짜내야할지 생각하다 그냥 하던대로 Test Code를 짜놓으면 되는건지 싶어서 정리를하게 되었다.
채용공고들을 보면 많은 회사들이 TDD 개발을 하는 것 같다. 퇴사한 회사도 마찬가지로 TDD 개발을 해왔지만, 시간이 너무 오래걸린다고만 생각을 했지만 점차 Test Code의 중요성을 갖고 오래걸리더라고 TDD 개발을 해오려고 노력했다.
TDD란?
💡 Test Driven Development의 약자로 테스트 주도 개발이란 뜻으로 Test Code를 먼저 작성 후 프로그래밍을 하는 과정을 말한다.
위 설명과 같이 TDD 프로세스는 다음과 같이 세 가지로 나뉜다.
- RED (Test 실패)
- 구체적인 하나의 기능에 대해서 하나의 Test를 추가하고, Test가 실패하는지 확인하는 단계.
- Test가 실패를 해야 해당 Test가 신뢰성이 있다고 볼 수 있다.
- 이 때, 실패하는 이유가 Test Code의 문제가 아니여야 한다.
- GREEN (Test 성공)
- 모든 Test에 대해서 코드가 성공을 하도록 코드를 수정하는 단계
- Test 성공을 위해서는 최소한의 코드 변경이 이뤄져야한다.
- 그 이유는 필요 이상으로 코드가 변경이 된다면 다른 단계에서 악영향을 끼칠 수 있다.
- REFACTORING
- 코드 베이스를 정리하고, 가독성과 적용성 및 성능을 고려해서 구현과 설계를 해야한다.
TDD의 장단점
장점
- 보다 튼튼한 객체 지향적인 코드 생산 가능.
- TDD는 코드 재사용 보장을 명시하므로 TDD를 통해서 개발 시 기능별 철저한 모듈화가 이뤄진다.
- 종속성과 의존성이 낮은 모듈로 조합된 개발을 가능하게 한다.
- 필요에 따라 모듈을 추가하거나 제거해도 전체 구조에 영향을 끼치지 않는다.
- 재설계 시간 단축
- Test Code를 먼저 작성하기 때문에 개발자가 지금 무엇을 해야할지 명확하게 정의를 하고 개발을 시작한다.
- Test 시나리오를 작성하면서 다양한 예외사항에 대해서 생각을 할 수 있다.
- 개발 도중에 구조 전반적인 설계가 변경되는 일을 방지할 수 있다.
- 디버깅 시간 단축
- 자동화 된 Unit Testing을 전제하므로 특정 버그를 쉽게 찾을 수 있다.
- Test 문서의 대체 가능
- Testing을 자동화 시키면서 동시에 보다 정확한 Test 근거를 산출할 수 있다.
- 추가 구현의 용이함
- 자동화된 Unit Testing을 전제하므로 Test 기간을 획기적으로 단축시킬 수 있다.
단점
- 생산성 저하
- 처음부터 2개의 Code를 짜야하고, 중간에 Test를 하면서 고쳐나가야 한다.
- TDD 개발 시간은 일반적인 개발 방식에 비해 대략 10% ~ 30% 정도 늘어단다.
이렇게 정리를 하면서 회사에서 했던 것을 생각해봤을때 어느정도 많이 느낀것 같다. 일반적인 개발 방식보다 시간이 엄청 늘어났지만, 그래도 안정적으로 API를 짤 수 있어서 좋았던 거 같다.
예전에 다른 블로그를 운영해서 적어내려갈 때는 무슨 소리인가 싶었지만 실전으로 해보니 많이 와닿는 거 같아서 궁금한게 있으면 우선 실전으로 부딪히는 방법도 나쁘지 않을 거 같다.