[TDD를 적용해보자 1편]TDD란?(Test-Driven-Development)

TwentyFiveSeven·2021년 1월 5일

TDD(Test-Driven-Development)란?

이해하기 쉽게 일반 개발 방식과 TDD 개발 방식을 비교해보겠습니다.

일반 개발 방식

우리가 일반적으로 개발하는 방식은 위 사진처럼 설계 -> 개발 -> 테스트 -> 배포의 형태를 갖습니다.
이러한 개발 방식은 몇가지의 문제점을 발생시킵니다.
1. 테스트가 실패하게 되면 매번 설계단계로 다시 돌아오게 되어 많은 시간이 소요됩니다.
2. 작은 기능 수정에도 모든 부분을 함께 테스트해야하기 때문에 테스트 비용이 증가됩니다.

TDD 개발 방식

우선 TDD가 왜 필요한지 부터 알아봅시다.

TDD는 애자일한 방법으로 개발에 도움이 됩니다.
- 애자일에서 중요한 것은 피드백과 협력입니다.
- TDD 또한 피드백과 협력을 증진시키는 방식이고, 이는 곧 불확실성이 높은 작업에 도움을 주는 것입니다.

이미 검증된 방법이고, 결과가 뻔한 작업이라면 TDD를 하지 않아도 됩니다.
테스트해야하는 방식이 너무 복잡하지만, 얻을 수 있는 결과가 정말 보잘 것 없다면 하지 않는 것이 더 좋습니다.
TDD를 적용해야할 대표적인 상황들
- 처음해보는 프로젝트의 주제
- 고객의 요구조건이 얼마든지 바뀔 수 있는 프로젝트
- 개발하는 사람과 유지보수하는 사람이 서로 다른 사람일 때
즉 불확실성이 높을 때 TDD를 진행하면 됩니다.

애자일한 방법인 TDD는 피드백과 협력에 도움이 됩니다.

일반적으로 테스트할 때 사용하는 방법은 다음과 같습니다.
- 결과 찍어보기
- 문자 출력해보기
하지만 TDD는 기록으로 남깁니다.
- 이말은 곧 다른사람들이 직접 테스트코드를 돌릴 수 있고, 결과를 확인할 수 있다는 것입니다.
이러한 방식으로 개발을 진행한다면 다음과 같은 장점이 있습니다.
- 코드를 통해 개발자의 의도를 파악하는 능력이 증가합니다.
- 한번에 길고 많은양의 코드를 보는 것이 아니라 순서대로 이어지는 테스트코드를 보며 코드의 의도를 쉽게 파악할 수 있습니다.

부스트캠프를 하면서 느낀 것은 TDD에 대한 필요성은 어느정도 강조해줬지만, 나 역시 그랬듯이 생각보다 시도조차 해보지 않은 사람들이 꽤 있었습니다.
왜 이러한 현상이 생겼고, 어떻게 TDD를 접근해야할지 알아가 봅시다.

정해진 규칙이 있기 때문에 결국에는 불필요한 반복되는 작업이라고 생각합니다.
TDD는 애자일한 방식이기 때문에 이러한 문제를 피드백과 협력을 통해 해결하고, 정해진 규칙에서 벗어난다면 다양하고 더욱 애자일한 방식이 될 수 있습니다.

적응, 진화의 측명으로 접근해봅시다.

피드백과 협력의 측면을 어떻게 끌어올릴지 생각하고 고민하면서 발전해 나가야한다.
- 간단한 예시는 자주 이뤄지는 피드백과 피드백을 통해 이뤄지는 협력입니다.
피드백과 협력의 측면을 끌어올리는 방법은 TDD를 적용하는 것 입니다.
- 어떤 작업이 3단계로 이루어져있습니다.
- 3단계의 피드백을 얻기위해서는 1단계, 2단계 테스트도 함께 이루어져야합니다.
  - 이러한 방식은 테스트 비용을 증가시키게됩니다.
- 때문에 TDD를 통해 3단계 테스트를 바로 진행할 수 있도록 개발하여 테스트 비용을 감소시킬 수 있습니다.
중복적으로 하는 노력들을 자동화되도록 개발하여 발전할 수 있습니다.

부지런한 웹개발자🌙