항해 플러스 프론트엔드 코스란?
1~4년 차 주니어 프론트엔드 개발자들이 모여 매주 토요일마다 오프라인 모임, 코드 리뷰를 진행하고
평일에 한 번씩 멘토링을 진행하면서 주니어 개발자들이 성장할 수 있는 환경을 제공해 주는 코스입니다.
이전 7주 차 후기 글인 [7. 테스트 코드가 어렵게 느껴지는 이유]와 이어지는 글입니다.
이번 항해 플러스 프론트엔드 코스 8주 차에선 TDD에 대해서 배웠습니다.
과제를 통해 직접 TDD를 해보면서 어떤 것들을 배웠고, 어떤 테스트 전략들이 있는지 작성해 보려 합니다.
TDD를 해본 후 내 생각은
“왜 하는 거지..?”
TDD를 처음 해보고 느낀 솔직한 소감은 "왜 하는 거지?"라는 의문이었습니다.
저는 보통 기능 구현 → 리팩토링 → 테스트 코드 작성의 순서로 개발하는 습관이 있습니다.
하지만 TDD는 테스트 코드 작성 → 기능 구현 → 리팩토링 순서로 진행되는 방법론이기 때문에, 코드를 작성하면서 이 새로운 방식에 익숙해지기가 쉽지 않았습니다.
TDD에서는 첫 번째 단계인 RED 단계에서 테스트 코드를 작성하고, 두 번째 단계인 GREEN 단계에서는 테스트를 통과시키기 위해 필요한 최소한의 코드를 작성합니다.
하지만, 실제로는 GREEN 단계에서 계속 코드 구현에만 집중하게 되어, 다시 RED 단계로 돌아가 새로운 테스트 코드를 작성하는 것이 어려웠습니다.
결과적으로, TDD의 순환 구조를 제대로 따르기보다는 익숙한 방식대로 기능 구현에만 집중하게 되더군요.
이 과정에서 느낀 점은 TDD가 분명히 장점이 있지만, 기존 개발 습관과 다르기 때문에 처음에는 적응하는 데 어려움이 있을 수 있다는 것입니다.
개발 사이클이 불편하지만, 강력한 장점
TDD(Test-Driven Development)는 개발 사이클이 다소 불편할 수 있지만, 그만큼 강력한 장점이 있습니다.
안정적인 컴포넌트 설계
TDD를 적용하면서 느낀 가장 큰 장점은, 구현에 들어가기 전에 해당 기능을 어떻게 설계할지 깊이 고민할 수 있다는 점입니다.
개발 경험이 쌓이다 보면, 특정 기능을 개발할 때 머릿속에 대략적인 설계가 떠오르기 마련입니다. 그러나 이 추상적인 설계를 바탕으로 빠르게 개발을 진행하다 보면, 실수하거나 미흡한 코드를 작성하는 경우가 발생할 수 있습니다.
TDD는 이러한 실수를 미리 방지하는 데 도움이 됩니다.
요구사항에 따라 테스트 코드를 먼저 작성하면서, 엣지 케이스를 사전에 파악할 수 있고, 어떻게 설계할 것인지에 대한 고민도 자연스럽게 이루어집니다. 테스트 코드 작성 과정에서 요구사항을 정리하면서, 설계적인 측면에서 더욱 꼼꼼하게 코드를 작성할 수 있게 되는 것입니다.
결국, TDD는 단순히 기능 구현의 정확성을 높일 뿐만 아니라, 안정적이고 신뢰할 수 있는 설계를 가능하게 해줍니다.
TDD를 언제 적용해야 할까?
하지만 이런 TDD 방법론은 항상 적용할 수 없다고 생각합니다.
그 이유는 시간이 너무 오래 걸리기 때문이죠,,,
TDD 과제를 진행하면서 간단한 기능도 30분 ~ 1시간 동안 고민하면서 코드를 작성하게 되었습니다.
대부분의 스타트업 기업은 개발 싸이클이 빠르게 굴러가야 하므로 TDD를 적용한다면, 개발 일정이 미뤄지게 될 수도 있습니다.
그래도 TDD를 적용하면 큰 이점이 있는 상황들이 존재합니다.
1. 요구사항이 명확할 때
TDD는 개발 요구사항이 명확할 때 특히 효과적으로 적용할 수 있습니다.
하지만, 만약 TDD를 적용하는 도중에 요구사항이 자주 변경된다면 어떻게 될까요?
그 경우, 테스트 코드를 계속해서 수정해야 하며, 이전 요구사항과 현재 요구사항이 혼재된 테스트 케이스들이 생겨날 수 있습니다. 이는 테스트의 신뢰성을 떨어뜨릴 뿐만 아니라, TDD의 핵심 이점인 안정적인 설계를 불안정하게 만들 수 있습니다.
결과적으로, 개발 속도는 느려지고 설계가 불안정해지면서 TDD를 적용하는 이점이 사라지게 됩니다.
따라서, TDD는 요구사항이 명확하게 정의되어 있고, 변경 가능성이 적을 때 적용하는 것이 가장 효과적입니다.
2. 테스트코드가 없는 컴포넌트를 리팩토링할 때
두번째로 테스트 코드가 없는 컴포넌트를 리팩토링할 때 적용하면 좋습니다.
"리팩토링 후에 기존 기능이 제대로 동작하지 않으면 어떡하지?"
이러한 우려를 덜어주기 위해, TDD를 활용하면 리팩토링의 안정성을 크게 높일 수 있습니다.
먼저, 리팩토링할 컴포넌트의 설계를 테스트 코드로 작성합니다.
이 과정에서 일부 테스트는 통과할 수도 있고, 일부는 실패할 수도 있습니다.
그런 다음, 컴포넌트를 리팩토링하면서 이 테스트들이 모두 통과되도록 코드를 수정합니다.
이렇게 하면 기존 기능을 안정적으로 유지하면서도, 보다 효율적이고 깔끔한 코드로 개선할 수 있습니다.
TDD를 적용한 리팩토링은 코드의 품질을 높이고, 기능 유지보수의 리스크를 줄이는 데 큰 도움이 됩니다.
여기서 자주 오해하는 부분이 있는데, TDD는 항상 새로운 기능을 개발할 때 적용하는 것이 아니라 이렇게 기존에 있는 코드를 리팩토링할 때에도 적용할 수 있습니다!
마무리
이렇게 TDD를 직접 해보면서 느꼈던 점과, 언제 TDD를 적용하면 좋은지 정리해보았습니다.
이전 글에서 테스트 코드 작성의 중요성을 강조했던 것처럼, TDD도 직접 경험해보는 것이 큰 도움이 된다는 점을 깨달았습니다.
다만, 실제 현업에서 바로 TDD를 적용하기는 쉽지 않을 수 있습니다. 처음부터 TDD를 적용하려고 하기 보다는 리팩토링 단계에서 테스트 코드를 작성하고, 그에 맞춰 코드를 수정해보는 방식으로 TDD를 간접적으로 경험해보는 것도 좋은 방법일 것 같습니다!
8주차 한 줄 후기
이번 8주 차에서는 TDD와 E2E 테스트를 직접 경험해볼 수 있어서 정말 좋았습니다.
사실 현업에서는 실제 기능 구현에 바빠 TDD를 적용하며 설계를 깊이 고민할 시간이 많지 않습니다.
하지만 이번 항해 플러스 프론트엔드 코스 과제를 통해 요구사항에 맞춰 TDD로 구현해보니, 생각보다 어렵지 않다는 걸 느꼈습니다.
또한, E2E 테스트를 과제에 적용해보았는데요.
이전에 통합 테스트와 유닛 테스트를 작성해본 경험이 있어서인지, E2E 테스트도 생각보다 쉽게 적용할 수 있었던 것 같아요.
특히, 멘토님께서 하셨던 "하나를 깊게 배우면, 유사한 것들은 어렵지 않아요"라는 말씀이 크게 와닿았던 8주 차였습니다.
긴 글 읽어주셔서 감사합니다!
⭐️ 항해 플러스 프론트엔드 코스 4기 모집
제가 현재 참여하고 있는 항해 플러스 프론트엔드 코스가 4기를 모집하고 있다고 하여 공유드립니다!
10월 24일까지 신청하시면 얼리버드 혜택으로 약 50% 할인을 받으실 수 있습니다.
또한 추천인 제도로 [추천인] 코드에 “zmK2OE”를 입력하시면 20만 원 추가 할인 혜택이 있으니
관심 있으신 분들은 항해 플러스 공식 홈페이지에서 신청하시면 됩니다 :)
저의 후기 글을 보시고 항해 플러스 프론트엔드 코스 관련해서 궁금한 사항이 있으시다면 링크드인 메시지 또는 이메일 yoosioff@gmail.com으로 편하게 연락주세요.
