이 글은 제가 프로젝트에 3주간 TDD를 도입하고 느낀 점을 회고한 글입니다.

들어가기 앞서서

제가 TDD를 공부하고 도입하면서 도움이 되었던 자료들을 먼저 공유하고자 합니다.

테스트 주도 개발 책 ( 저자 : 켄트백 )

https://www.youtube.com/watch?v=cVxqrGHxutU&ab_channel=OKKY
( 박재성님 강의 )

https://jestjs.io/docs/en/getting-started
( jest 문서 )

그리고 절대 테스트 만큼은 양보하지 않겠다는 끈기!

TDD

(이미지 출처 https://www.codica.com/blog/test-driven-development-benefits/)

1. (RED) 테스트에 실패한다.
2. (GREEN) 테스트를 통과시킨다.
3. (Refactoring) 리팩토링으로 코드를 개선한다.

TDD는 일반 개발 프로세스와 달리 테스트 케이스를 먼저 작성하는 것으로 시작합니다.

테스트 먼저 작성하면 당연히 테스트가 실패하지 않을까요??

맞습니다. 코드가 없는 상태에서 유닛테스트를 실행하면 터미널에 빨간 글씨로 에러코드가 나오게 될 거에요. 테스트를 실패한 상태를 RED 라고 부릅니다.

TDD의 다음 단계는 실패한 RED 상태를 테스트를 통과한 GREEN 상태로 만드는 것이 목표입니다.

그 후 GREEN 상태의 코드를 계속 리팩토링하는 과정을 수행하며 RED - GREEN - Refactoring을 수행하는게 TDD의 개발 프로세스입니다.

어차피 실패하는 코드를 짜는게 의미가 있을까요?

저도 처음 TDD를 시작했을 때는 그런의문을 품었지만 TDD의 강력한 장점이 그런 의문을 상쇄시켰습니다.

장점1. TestCase를 짜는것 자체가 설계 & 문서화가 된다.

테스트 케이스를 짜기 위해서는 우리가 구현하고자 하는 함수나 클래스가
입력값을 받았을때 어떤 출력값을 만들어 내는지 정확히 인지하고 있어야 합니다.

이는 테스트 케이스를 구현하면서 우리가 구현하고자 하는 목표를 정확히 인지하게 되고 이를 테스트 코드로 옮겨 적으면서 간단한 문서화와 명세, 설계도 함께 완성이 되는 과정으로 이루어집니다.

TestCase를 보는 것 만으로 이 함수가 무슨 역할이고, 주로 어떠한 값을 뱉어내는지 어느 정도 추측이 되게 됩니다. describe를 보면 전체적인 흐름을 추측하는게 가능해 집니다.

TestCase를 먼저 짜는 것 만으로도 많은 이점이 있기 때문에 실패하는 코드를 짜는건 충분히 의미가 있다고 느꼈습니다.

장점2. Refactoring 에서의 장점

저는 TDD를 도입하기 전에 코드 Refactoring을 하는 것이 정말로 무서웠습니다.

저의 코드는 도미노와 같이 민감해서 같은 로직이지만 로직의 순서를 변경하는 것 만으로도 프로그램 전체가 기능을 멈추는 경우가 많았고 그러한 경험이 축적되어서

Refactoring을 수행하면 반드시 어딘가 고장이 난것 같은 기분이 들어 육안으로 하나하나 체크하면서 테스트를 했던 경험이 많았습니다.

특히 부스트캠프 처럼 마감일이 있는 상황에서는

굳이 리팩토링을 해야할까? 잘 작동하는데? 오히려 건들었다가 안돌아가면 나만 손해 아니야?? 마감일이 내일모래인데??????

라는 생각으로 넘어갔던 경험이 많았습니다.

하지만 TestCode가 있으면 이런 고민을 하지 않아도 됩니다.

TDD를 하게 되면 코드를 작성하기 전 TestCase를 먼저 작성하기 때문에

작성하는 코드가 많아질수록 TestCoverage도 함께 증가합니다.

리팩토링을 해서 코드가 변경되어도 Jest 명령어 하나로 어느 부분에서 오류가 발생하는지. 코드의 정상 작동 여부를 알 수 있으므로 Refactoring 작업을 할때 엄청 도움이 되었습니다.

어느 부분이 고장났는지. 고쳐야 하는지 정확히 알게 되고 그 부분만 다시 고치면 되기 때문에 Refactoring 작업이 수월하게 돌아갑니다.

촘촘한 테스트 커버리지로 버그가 숨을곳이 없어지게 됩니다. 덤으로 초록글자가 많이 보이면 성취감도 2배로 증가하게 됩니다.

특히 TestCode들은 리팩토링을 할 때 진가가 발휘하게 됩니다. 정말 안정적으로 코딩하고 있다는 기분이 들게 만들어 줍니다.

장점 3. 코드에 대한 신뢰성 증가

테스트를 통과한 코드들로 구성되었기 때문에 코드에 대한 신뢰가 생기게 됩니다. 그리고 개발도 더 적극적으로 임하게 된것 같았습니다.

정리

3주간 TDD를 실천하려고 노력하면서 느낀 점은

TDD는 정말 정성이 필요한 작업이라고 생각했습니다.
하지만 프로그램의 크기가 커질수록 그 진가가 드러나는 작업이라고 생각했습니다.
특히 리팩토링에서 엄청난 진가를 발휘합니다.

꼭 TDD가 아니더라도 테스트 코드는 무조건 있어야 한다고 생각하게 된 계기가 되었습니다.