TDD에 대하여

※ 개인 공부를 위한 공간입니다. 틀린 부분 지적해주시면 감사하겠습니다 (_ _)

 

 

TDD를 공부하게 된 계기

TDD(Test Driven Development, 테스트 주도 개발)에 대해서는 동료 개발자들과 토의 중 몇번 들어본 단어였다.

영어를 공부할 때에도, 모르는 단어가 있으면 찾고 이해하기 전까지 그 자리에 서서 절대 움직이지 않았던 것 처럼..

인터넷에 바로 찾아보았다.

처음 이해한 TDD는 대략 이런 내용이었다.

"테스트 코드를 먼저 작성 후, 실제 코드로 옮기는 작업"

그런데 이상했다.

"실제로 코드를 짤 때에도 여러가지 상황을 생각한 뒤 테스트를 해보고 실제 코드를 완성시키는데, 당연한 거 아닌가?"

라는 생각이 들었고, 실제로 TDD라는 개발 방식을 어떻게 적용하고 코드를 짜는지 영상을 보게 되었다.

https://www.inflearn.com/course/%EB%94%B0%EB%9D%BC%ED%95%98%EB%A9%B0-%EB%B0%B0%EC%9A%B0%EB%8A%94-tdd/dashboard

따라하며 배우는 TDD 개발 - 인프런 | 강의

NestJS 및 자동화 배포 관련하여 John Ahn 선생님의 도움을 참 많이 받았다. 이자리를 빌어 감사드립니다..

 

내게 필요했는가? 그리고 앞으로 필요한가?

위에 언급했던 것 처럼, 지금까지 설계 및 개발을 끝내고 전체 코드를 테스트 했었다.

당연히 맞닥뜨릴 수 있는 오류들만 거를 수 있었다.

(그럼에도 불구하고 실제 사용시 잡지 못한 에러들이 많았다. 경험이 쌓이면 쌓일수록 에러 핸들링도 잘하는 줄 알았다.)

팩트는, 그랬다면 대기업에서 만드는 서비스들엔 오류가 없어야 한다...

(실제로 대기업에서는 TDD방식으로 개발을 진행하며 7~90%정도를 커버하는 테스트 코드들이 존재한다고 한다! 헐!)

또한, 크롤러를 만들면서 엄청난 오류들이 존재했고, 타입스크립트를 보면서 열광했던 나이기에 TDD 방식의 개발은 필.수.였.다.

안 할 이유가 없다.

그럼 어떤 장단점들이 있을까?

 

TDD의 장단점

1. 개발 시간이 늘어난다.
   • 대략 10~30%가 늘어난다고 한다.
   • 초기 비용은 훨씬 크다.
   • 일정 시간이 지나면, 시간 대비 비용이 더 커지지 않는다고 한다.
2. 결함이 줄어든다.
   • 1/2 ~ 1/10까지 줄어든다고 한다. (버그를 줄일 수 있다.)
   • 설계 및 코드 수정시 새로운 오류를 만들어 낼 확률을 매우 줄여준다.
3. 코드 복잡도가 떨어진다.
   • 깨끗한 코드가 나오며, 유지보수 비용이 낮아진다고 한다.
4. 어렵다.
   • 지금까지 개발하던 방식과 많이 바꿔야 한다. (개발을 안 해본 사람들에게 적용이 더 쉽다고 한다.)
5. 과거 의사결정을 쉽게 상기시킬 수 있다.
   • 왜 특정 테스트 코드를 작성하였는지 확인하기가 쉽다.
6. 완료시 테스트 비용이 매우 낮아진다.
   • 개발 완료 시 테스트 비용이 거의 들지 않는다.
   • 작은 기능 수정에도 모든 테스트를 할 필요가 없음.
7. 코드에 대한 신뢰도가 높아진다.
   • 테스트를 많이 한 코드이기 때문에 신뢰도가 높아진다.

코드 품질을 올리고, 틀에 박힌 습관을 바꾸기 위해서라도 어느 정도의 위험 부담은 감수하자!

 

TDD 개발은 어떻게 진행되는가?

테스트 실패(RED) > 테스트 성공(GREEN) > 리팩토링(YELLOW) > 테스트 실패(RED) > ....

 - 디자인 단계에서 목적 설계
 - 무엇을 테스트 할 것인지 미리 정의
 - 예외 및 버그 테스트 케이스 추가
 - 설계 개선

구현해야 할 기능을 정의한 후 (요구사항 정의)
어떻게 만들 것인지 설계를 한다. (디자인 설계)
--- 여기까지는 기본 개발방향과 동일하다.
어떤 테스트들을 진행할 것인지 정의한 후 (테스트 케이스 추가)
케이스들에 맞는 mock 객체(데이터, 함수 등)들과 함께 테스트 코드 작성 (테스트 코드 작성 및 테스트 > 실패 & 성공)
테스트 코드를 기반으로 실제 코드를 작성한다. (리팩토링)
리팩토링 기반 테스트를 재진행한다. (실패 & 성공)
--- TDD의 테스트 주도형 개발

기본 개발은
설계 > 구현 > 테스트 > 재설계 > ...

TDD 개발은
설계 > 테스트 > 구현 > 재설계 > ...

한 마디로,
기존과 같이 작성한 코드를 테스트 하는 코드를 짜는 것이 아니라
테스트 코드를 짜면서 개발을 완료하는 것이다!

추가:
Mock 객체란 무엇이며 어떻게 활용해야 하는가?
Mock 객체란, 말 그대로 mock(가짜의, 모의의) 데이터를 만드는 것이다.
기능을 다 구현했다면, mock 데이터가 필요하지 않겠지만, 실제로 데이터를 불러오는 환경을 구성하지 않은 상황에선 필수적이다.
아직 구현하지 않은 모듈이나, 테스트에 필요한 객체를 생성해 테스트 환경을 손 쉽게 구현할 수 있어 기능에 더 집중할 수 있다.
테스트 코드 작성시, 필요한 데이터가 무엇인지 정의하게 되며 실제로 필요한 데이터(http 통신 등을 통해 가져와야 할 시)를 통해 이후 작업을 하게 될 때 mock 객체를 생성하면 된다!
하지만 지나치게 사용하게 되면, 테스트 코드의 의미가 없어진다. (Mock 객체는 실제 데이터가 아니기 때문에!)
또한 지나치게 많은 Mock 객체가 필요하면, 리팩토링의 의미가 있는지 파악해보는 게 중요하다고 한다.

 

테스트의 종류

• 단위 테스트
  • 테스트 가능한 가장 작은 단위로 나누어 예상대로 동작하는지 확인하는 테스트
• 통합 테스트
  • 단위 테스트들을 모아 의도대로 동작을 하는지 확인하는 테스트
• 인수 테스트
  • 시나리오에 맞춰 수행하는 테스트

 

 

자, 이제 개념적인 부분은 숙지하게 되었고, 실제로 구현해보는 일만 남았다!
다음 시간엔 "단위 테스트"에 대해서 알아보겠다.
Way to go!

 

 

참고:

https://gmlwjd9405.github.io/2018/06/03/agile-tdd.html

https://media.fastcampus.co.kr/knowledge/dev/tdd/

https://velog.io/@modolee/tdd-overview

https://tecoble.techcourse.co.kr/post/2021-05-25-unit-test-vs-integration-test-vs-acceptance-test/