TDD - 테스트 주도 개발 part.1

갑자기 ?

사실, 해야지 해야지 생각만 했던 TDD.. 현재 재직 중인 회사에서 서버 개발할 때 진짜 해보고 싶었던 건데 마땅히 시간이 없었다. (핑계 아니에요🤣..) 근데 회사 동료 개발자님이 스터디를 해보지 않겠냐는 좋은 제안을 해주셔서 일단 덥석 물었다. (역시, 사람은 저지르고 보는 거지(?)) 모각코나 멘토링은 요즘에도 종종 하고 있지만 스터디 경험은 적어서 잘 마무리될지 걱정이 많지만. 어쩌겠는가, 언제나 그렇듯 하기로 했으면 하는 것이다!!👊 일단 책부터 완독하려고 한다. 그 유명한 켄트 백씨가 쓴 ‘테스트 주도 개발’이다. ‘무조건 이걸 쓰겠다!’ 말고 일단 ‘왜?’에 집중해서 TDD의 필요성을 머리로 이해하고, 실습을 해보려고 한다. 그리고 나중엔 “TDD는 죽었다.” 라고 말하는 사람들의 이야기도 살펴보려고 한다.

테스트 주도 개발 1,2부

1부에서는 테스트 주도 개발의 흐름에 대해서 쉬운 예제들로 길게 설명했다. 그래서 엄….청 지루했다 😪 dollar,,franc,,money,,🥱 돈 최고 👍(?) 2부에서는 xUnit이라는 테스팅 프레임워크를 설명하려는건가..?싶었지만 2,3번 다시 읽어도 이게 테스팅 프레임워크에 대한 설명인지 테스트를 위한 테스트 설명인지..🤔 모르겠다. 그래서 일단 틀에 얽매이지 않고 이 책에서 언급된데로 테스트 주도 개발의 리듬을 이해하는데 힘썼다.

TDD Flow : Test Driven Development Flow

테스트 주도 개발은 아래 이미지처럼 세 가지 큰 흐름이 있다.

TDD-Flow

1. RED

실패하는 작은 테스트를 작성하는 단계.

컴파일조차 되지 않는 실패할 테스트 코드를 작성한다. 존재하지 않는 객체, 함수들을 있는 척해도 된다. 개발할 기능에 필요한 모든 테스트를 이 단계에서 작성한다. 쉬운 테스트부터 빠르게 작성하도록 한다.

2. GREEN

빨리 테스트가 통과하게끔 만든다. 이를 위해 어떤 죄악을 저질러도 좋은 단계.

개인적으로, TDD를 몸에 익히는 과정에서 제일 적응하기 힘든 단계가 아닐까 싶다😅. 여기서 말하는 죄악이라는 워딩이 강렬해 머릿속에 오래 남았다. 죄악😈이란 뭔지 알아보자.

RED 구간에서 실패할 테스트 코드를 작성했으니 일단 뭐가 됐든 통과만 시킨다. 이 통과 딱지를 받기 위해 하드코딩을 해도 좋고 스택오버플로우에서 코드를 대충 복붙해도 좋다. 변수명이 temp여도 좋다. 일단, 무조건 모든 테스트를 통과시키는 것에만 집착한다. 그래서 죄악이라 부르나보다. 그니까.. 3-5분만 투자해 당장 개선할 수 있는 코드를 눈 앞에 두고 일말의 망설임 없이 치고 나가야만 한다. 개인적으로 손이 빠른 편은 아니지만, 아무리 그래도 당장 개선할 수 있는 코드를 눈 앞에 두고 지나친다는게 쉽지 않을것 같다😅. 죄악을 저지르는 개발자들에게 정신적 데미지를 줄이기 위함인지, GREEN은 최대한 짧고 빠른 시간내에 처리하길 권장한다.

3. REFACTORING

일단 테스트를 통과하게만 하는 와중에 생겨난 모든 중복을 제거하는 단계.

GREEN 단계에서 저지른 죄악을 모두 용서받을 수 있는 구간이다!😁 눈앞에 놓고 지나쳤던 개선 가능한 코드들을 수정하고 내 머릿속에 있는 프로그래밍 지식을 최대한 뽐내며 개발할 수 있는 단계이다. 그래서 Refactoring이라고 네이밍 된 것 같다. 여기서 힐링되지 않는다면 TDD와 사이가 멀어지기만 할 것 같다.

TDD의 장점 ?

테스트 코드를 66잘99 작성한다는 전제로 장점은 어떤 것들이 있을까?

1. 버그가 적거나 없을 것.
   • 예상하지 못했던 경우가 아니라면 모든 시나리오에 대해 테스트 코드를 작성후 개발해 통과한 상태로 배포됐을 테니 버그가 적거나 없다.
2. OOP를 OOP답게 개발.
   • RED,GREEN 구간에서 짧은 시간을 가져가고, 리팩토링에 시간을 더 할당하기에 조금 더 완성도 높은 코드를 작성할 수 있겠다. TDD는 중복제거를 강조하고 의존성과 종속성이 낮은 개발을 추구하여 기능, 모듈을 추가해도 소프트웨어 전체에 영향을 끼치지 않게끔 할 수 있다.
3. 유지 보수 향상.
   • 리팩토링 단계에서 가독성 좋은 코드로 개발했다면, 아무래도 유지 보수성이 향상될 것 같다.

TDD의 단점 ?

반대로, 테스트 코드를 잘 작성하지 않는다면?

1. 개발 시간이 더 길어진다.
   • 기존과 다른 개발 방법을 선택했기에 러닝 커브가 있을 것이고 익숙해진다 해도 전체적인 개발 시간은 더 길어질 것 같다.
     시간이 넉넉하다면 상관없겠지만 서비스를 빠르게 출시해야 하는 상황에 놓여 있다면.. 조급함에 지칠 것 같다.