서론

약 한 달 전 테스트가 어렵지 않은 이유에 이어 테스트 코드에 대해 정리해보려고 합니다. 항해 플러스 WIL는 꼭 작성하고 넘어가고 싶어서... 다소 많이 밀리긴 했지만 작성해보려고 합니다.

실무에 적용하려고 애를 쓰고 있지만 학습이 더욱 필요하다는 것을 느꼈습니다.

TDD 과제를 다시 한번 살펴보았습니다. 이 과정에서 어떤 것들을 배웠고, 어떤 테스트 전략들이 있는지 작성해 보려 합니다.

이 블로그를 시작으로 테스트 코드 작성에 우선순위를 높이려고 합니다. 더 나아가 실무 백엔드 프로젝트에도 적용해보려고 합니다. 작은 스타텁이라 다양한 환경을 경험할 수 있는 이 장점을 놓칠 수 없죠.

본론

TDD를 경험하고 나의 생각은

“왜 하는 거지..? 내 상황에 적용 가능한건가...?”

TDD를 처음 경험하고 든 생각은 "왜 하는 거지?"입니다. 실무 프로젝트에 적용할 수 없는 것 같다고 생각했습니다. 왜냐하면 기획이 명확하지 않고 수시로 바뀔 수 있다는 점 때문이죠.

최근 테스트 코드를 공부하면서 실무에 작게라도 적용하려고 노력을 하고 있습니다. 그래서 기능 구현 → 리팩토링 → 테스트 작성의 순서로 개발하고 있습니다.

하지만 TDD는 테스트 코드 작성 → 기능 구현 → 리팩토링 순서로 진행되는 방법론이기 때문에, 코드를 작성하면서 이 새로운 방식에 익숙해지기가 쉽지 않았습니다.

TDD에서는 첫 번째 단계인 RED 단계에서 테스트 코드를 작성하고, 두 번째 단계인 GREEN 단계에서는 테스트를 통과시키기 위해 필요한 최소한의 코드를 작성합니다.

하지만 테스트를 통과시키기 위해 필요한 최소한의 코드를 작성하는 방법에 대한 감이 없었습니다. Green 단계에서 모든 것을 구현한 후, Red로 넘어가게 돼, 이게 맞는 TDD인가 싶었습니다. 경험해보지 못해서 몰랐던 부분이었고 TDD의 순환 구조를 따르지 않고 저에게 익숙한 방식의 개발을 진행했었습니다.

이 과정에서 느낀 점은 TDD가 분명히 장점이 있지만, 기존 개발 습관과 다르기 때문에 처음에는 적응하는 데 어려움이 있을 수 있다는 것입니다.

익숙하지 않지만 좋은 점이 있습니다.

TDD(Test-Driven Development)는 개발 사이클이 익숙하지 않아 불편할 수 있지만, 그만큼 강력한 장점이 있습니다.

안정적인 컴포넌트를 설계할 수 있다는 것.

TDD를 적용하면서 느낀 가장 큰 장점은, 구현에 들어가기 전에 해당 기능을 어떻게 설계할지 깊이 고민할 수 있다는 점입니다.

개발 경험이 쌓이다 보면, 특정 기능을 개발할 때 머릿속에 대략적인 설계가 떠오르기 마련입니다. 그러나 이 추상적인 설계를 바탕으로 빠르게 개발을 진행하다 보면, 실수하거나 미흡한 코드를 작성하는 경우가 발생할 수 있습니다.

TDD는 이러한 실수를 미리 방지하는 데 도움이 됩니다.

요구사항에 따라 테스트 코드를 먼저 작성하면서, 엣지 케이스를 사전에 파악할 수 있고, 어떻게 설계할 것인지에 대한 고민도 자연스럽게 이루어집니다. 테스트 코드 작성 과정에서 요구사항을 정리하면서, 설계적인 측면에서 더욱 꼼꼼하게 코드를 작성할 수 있게 되는 것입니다.

결국, TDD는 단순히 기능 구현의 정확성을 높일 뿐만 아니라, 안정적이고 신뢰할 수 있는 설계를 가능하게 해줍니다.

TDD를 적용하면 좋은 상황은?

완벽하게 TDD를 적용할 수 없다고 생각합니다. 모든 회사의 리소스(시간)에 제한이 있기 때문입니다. 주어진 기능을 당장 내일까지 만들어야하는 상황에서 TDD를 적용하기엔 어려움이 있었습니다.

TDD 과제를 진행하면서 간단한 CRUD 기능도 대략 1시간 동안 고민하면서 코드를 작성했습니다. 대부분의 스타트업 기업은 개발 싸이클이 빠르게 굴러가야 하므로 TDD를 적용한다면,,, 일정이 미뤄질 수 도 있습니다.

그럼에도 불구하고 TDD를 적용하면 큰 이점이 있는 상황들이 존재합니다.

1. 개발 요구사항이 명확할 떄

TDD는 개발 요구사항이 명확할 때 특히 효과적으로 적용할 수 있습니다. 하지만, 만약 TDD를 적용하는 도중에 요구사항이 자주 변경된다면 어떻게 될까요?

그 경우, 테스트 코드를 계속해서 수정해야 하며, 이전 요구사항과 현재 요구사항이 혼재된 테스트 케이스들이 생겨날 수 있습니다. 이는 테스트의 신뢰성을 떨어뜨릴 뿐만 아니라, TDD의 핵심 이점인 안정적인 설계를 불안정하게 만들 수 있습니다.

결과적으로, 개발 속도는 느려지고 설계가 불안정해지면서 TDD를 적용하는 이점이 사라지게 됩니다. 따라서, TDD는 요구사항이 명확하게 정의되어 있고, 변경 가능성이 적을 때 적용하는 것이 가장 효과적입니다.

2. 테스트코드가 없는 컴포넌트를 리팩토링할 때

두번째로 테스트 코드가 없는 컴포넌트를 리팩토링할 때 적용하면 좋습니다.

"리팩토링 후에 기존 기능이 제대로 동작하지 않으면 어떡하지?"

이러한 우려를 덜어주기 위해, TDD를 활용하면 리팩토링의 안정성을 크게 높일 수 있습니다.

먼저, 리팩토링할 컴포넌트의 설계를 테스트 코드로 작성합니다. 이 과정에서 일부 테스트는 통과할 수도 있고, 일부는 실패할 수도 있습니다.

그런 다음, 컴포넌트를 리팩토링하면서 이 테스트들이 모두 통과되도록 코드를 수정합니다. 이렇게 하면 기존 기능을 안정적으로 유지하면서도, 보다 효율적이고 깔끔한 코드로 개선할 수 있습니다.

TDD를 적용한 리팩토링은 코드의 품질을 높이고, 기능 유지보수의 리스크를 줄이는 데 큰 도움이 됩니다.

여기서 자주 오해하는 부분이 있는데, TDD는 항상 새로운 기능을 개발할 때 적용하는 것이 아니라 이렇게 기존에 있는 코드를 리팩토링할 때에도 적용할 수 있습니다!

결론

이렇게 TDD를 직접 해보면서 느꼈던 점과, 언제 TDD를 적용하면 좋은지 정리해보았습니다.

테스트 코드 사용 경험, 그자체로 너무 귀한 것 같습니다. 마찬가지로 TDD도 직접 경험해보니 도움이 많이 됐습니다. 다만, 실제 현업에서 바로 TDD를 적용하기는 쉽지 않을 수 있습니다. 처음부터 TDD를 적용하려고 하기 보다는 리팩토링 단계에서 테스트 코드를 작성하고, 그에 맞춰 코드를 수정해보는 방식으로 TDD를 간접적으로 경험해보는 것도 좋은 방법일 것 같습니다!

과제를 통해 깨달은 점

TDD와 E2E 테스트를 경험해보았고 이 경험을 바탕으로 실무에서 사용해볼 생각을 하니 기대가 됩니다!!

현재 실무에서 기능 구현 혹은 기타 업무로 인해 바빠 TDD를 적용하며 설계를 깊이 고민할 시간이 많지 않습니다. 하지만 항해 플러스 프론트엔드 코스 과제를 통해 요구사항에 맞춰 TDD로 구현해보니, 그렇게 어렵지 않다는 걸 느꼈습니다. 기획 의도를 파악하여 요구 사항을 이해하고 엣지 케이스를 고민하면서 작성하도록 한다는 관점에서 TDD는 도움이 되는 것 같습니다.

테스트코드가 없는 컴포넌트를 리팩토링할 때 적용하면 좋다고 했듯 실무 프로젝트에 테스트 코드를 적용해보려고 합니다.

모두 각자의 위치에서 파이팅입니다.

⭐️ 항해 플러스 프론트엔드 코스 5기 모집

항해 플러스 프론트엔드 코스가 5기를 모집하고 있습니다.

https://hanghae99.spartacodingclub.kr/plus/fe

(추천인 코드 0BBFXj 를 입력하시면 수강료를 20만원 할인받을 수 있습니다)

관련 질문은 링크드인을 통해 부탁드립니다!