• 카테고리

    질문 & 답변
  • 세부 분야

    백엔드

  • 해결 여부

    미해결

현업에서도 TDD를 적극 활용하시는지 궁금합니다.

24.03.05 10:37 작성 조회수 296

0

우빈님 강의에서 말씀해주신 것 처럼 TDD를 활용하면 테스트 코드를 먼저 작성하기 때문에 테스트에 대한 강제(?)할 수 있으며, 엣지 케이스에 대한 식별을 빨리 할 수 있어 많은 장점이 있다고 생각합니다. 제가 생각했을 때는 TDD를 활용하지 못하는 상황은 시간적 여유가 없을 때라고 생각되는데 이 외 다른 이유도 있을까요? 또한, 우빈님께선 평소 TDD를 활용하여 프로덕션 코드를 작성하는지도 궁금합니다.(개발 기간이 부족할 때도 테스트 코드를 무조건 작성하는지도 궁금합니다😀)

답변 2

·

답변을 작성해보세요.

3

안녕하세요, 멍청한청년 님! (아이디를 쓰면서 죄송하다는 생각이..)

TDD를 사용하기 어려운 상황은 '시간이 없어서'도 있고, '내가 개발하려는 도메인 지식이 부족한 경우'도 있습니다.
낯선 기능을 개발해야 하는 경우, 도메인 지식이 아직 확보되지 않은 상황이기 때문에 처음부터 TC(테스트 케이스)를 나누고 접근하기가 어려울 수 있습니다.
이런 경우, 강의 마지막 즈음에 말씀드렸던 학습 테스트와 같은 도구를 사용해 도메인 지식을 확보하는 단계가 필요할 수 있습니다.

평소 저는 어떻게 하는지를 질문 주셨는데, 일단 케이스를 조금 나눠보면 아래와 같은데요.

  1. TDD를 사용하여 개발한다.

  2. TDD는 아니지만, 프로덕션 코드를 작성한 후 테스트 코드를 작성한다. (혹은 순서 상관없이 작성한다.)

  3. TDD, 테스트 코드 없이 프로덕션 코드만 작성한다.

저도 아주 급박한 장애 상황이 아닌 이상, 아무리 시간이 없더라도 최소 2번으로 접근합니다.
왜냐하면 테스트 코드가 주는 유익을 고려했을 때 당장은 시간이 오래 걸리는 듯 보이나, 전체 피쳐 개발에 드는 리소스가 더 적게 든다는 믿음이 있기 때문이에요. (실제로도 시간이 지나고 나서 보면 대부분의 경우가 그래왔습니다.)
테스트 코드가 없는 프로덕션 코드가 배포 전 검증 단계에 들어섰을 때, 그제서야 발견되지 못한 이슈가 발견되거나 하면 결국은 더 큰 비용을 소모하기 때문입니다.

시간이 충분한 경우에는 상황에 따라 1, 2번을 섞어서 사용하는데요.
개발하려는 내용의 케이스가 복잡하여 단순하게 접근하기가 어려운 경우는 1번, 반대로 케이스가 단순하고 개발해야 하는 난이도가 낮아서 프로덕션 코드와 테스트를 순서 상관 없이 거의 동시에 작성할 수 있는(TC 전체를 핸들링할 수 있는) 정도라면 2번으로 개발할 때도 있습니다.

 

TDD도 결국은 하나의 도구이기에, 본인의 것이 되기까지 숙달하는 단계에서는 필수라고 생각하는 것이 좋고요. 익숙해졌다 싶으면 필요한 상황에 맞게 적절하게 선택할 수 있는, 본인만의 연장으로 사용할 수 있어야 합니다.

 

도움이 되셨기를 바랍니다.
감사합니다. 🙂

0

인프런 AI 인턴님의 프로필

인프런 AI 인턴

2024.03.07

안녕하세요, 인프런 AI 인턴입니다.

우빈님 강의에 대한 질문 감사드리며, 저희는 인프런 AI 인턴이라 특정 강의에 대한 내용을 알려드리지는 못합니다만, 현업에서 Test-Driven Development(TDD) 접근 방식의 활용에 대해서는 답변드릴 수 있습니다.

TDD는 개발 초기부터 테스트를 중심으로 코드를 작성하기 때문에, 설계를 보다 견고하게 할 수 있으며 오류를 조기에 발견하고 수정할 기회를 줍니다. 또한, 리팩토링을 안전하게 진행할 수 있도록 도와주는 역할도 합니다. 그러나 TDD를 활용하지 못하는 상황에는 여러 가지 이유가 있습니다. 예를 들어, 프로젝트의 특성 상 빠르게 결과물을 내야 할 때, TDD에 익숙하지 않은 팀원들이 있을 때, 혹은 기존 프로젝트의 큰 규모와 복잡성으로 인해 TDD를 도입하기 어려울 때 등 다양한 경우가 있습니다.

개발 기간이 부족할 때에도 TDD를 적용하는 것은 팀이나 프로젝트의 방침에 따라 다릅니다. 품질을 최우선으로 하는 경우에는 기간 내에 제품을 완성하는 것보다 올바른 방법으로 제품을 만드는 것에 초점을 맞출 수 있습니다. 하지만 현실적인 상황에서는 시간, 자원, 우선순위 등 여러 요인을 고려하여 테스트 코드를 작성할지 결정하게 됩니다.

TDD에 대한 더 자세한 방법론과 도구는 “Spring Boot Reference Documentation”에서 찾을 수 있습니다. Spring Framework를 사용하여 TDD를 실천하는 방법에 대한 설명이 포함되어 있으니 참조하시면 도움이 될 것입니다. 아래는 관련 문서의 링크입니다.

즉, 현업에서 TDD의 적용 여부와 활용 정도는 프로젝트의 특성과 팀의 결정에 따라 다양하게 적용될 수 있습니다. TDD를 통해 얻을 수 있는 이점과 프로젝트의 요구 사항을 균형 있게 고려하는 것이 중요합니다.