[테코톡] TDD와 단위테스트

 

📚 참고자료

• 유튜브 채널 [우아한 Tect] - 10분 테코톡 피카의 TDD와 단위 테스트

https://www.youtube.com/watch?v=3LMmPXoGI9Q 

 

---

 

🤔 TDD란?

 

프로그램을 작성하기 전에 테스트를 먼저 하라!

- 켄트 백 Kent Beck -

 

• TDD (Test-Driven Development)
• 테스트 코드를 먼저 만들고, 실제 프로덕션 코드를 나중에 만드는 개발 방법을 말합니다.

 

 

 

기존 프로세스

 

 

TDD 방식 프로세스

 

 

 

🤔 TDD를 사용하는 이유는?

• 변화에 대한 두려움을 줄여준다. (리팩터링이 편하다)
• 디버깅 시간을 줄여준다.
• 동작하는 문서 역할을 한다.

 

 

 

😀 TDD의 장점

• TDD를 하면 자연스레 테스트 커버리지가 높아진다.
• 오버 엔지니어링을 방지할 수 있다.
  • TDD를 하면서 요구사항에 맞춰 개발 코드를 구현
  • 미래에 필요할 것 같은 구현을 지레짐작하여 불필요한 코드를 작성하는 소요가 줄어든다.
• 설계에 대한 피드백이 빠르다.
  • 설계를 처음부터 잘한다면 좋겠지만 잘못 설계했다면, 변경이 일어나거나 사용하기 어려울 때 깨달을 수 있다.
    반면에 TDD는 설계에 대한 피드백을 빠르게 해 줄 수 있다.
  • 설계가 복잡해지면 테스트 코드를 작성하기 점점 더 어려워진다.

 

 

😅 TDD의 오해

• TDD는 실제 방법론이다?
  • TDD는 높은 응집을 유도하지 않는다.
  • TDD는 단일 책임 원칙과 인터페이스 분리 원칙 위배에 어떤 신호도 주지 않는다.
  • TDD는 인터페이스 일관성을 도출하지 않는다.
  • TDD의 리팩터링 단계는 좋은 구조를 안내하거나 좋은 구조를 갖도록 강제하지 않는다.

 

 

 

😥 TDD를 실패하는 이유

• 코드가 이루고자 하는 가치나 기능을 테스트하기보다 그 기능을 어떻게 구현하고 있는지를 테스트한다.
• 결국 테스트 케이스들이 구현체와 결합도가 높아진다.
• 구현체들을 리팩터링 하면 결합되어있는 테스트 케이스들이 모두 깨져버린다.

 

 

 

 

📏 테스트의 범위

 

• 통합 테스트: 여러 작업 단위가 연계된 워크플로우를 테스트하기
  위한 수단(객체 간, 시스템 간)
• 기능 테스트: 공개된 API의 가장 바깥쪽에 해당하는 코드 검사
  (Controller 호출, Security, http)
• 부하 테스트: 주어진 단위 시간 동안 애플리케이션이 얼마나 많은
  요청을 처리할 수 있는지 검사
• 인수 테스트: 고객 또는 대리인이 정의된 모든 목적에 부합되는지
  확인해보고자 하는 검사

 

 

 

 

 

👍 좋은 단위 테스트

 

F.I.R.S.T 법칙

F - Fast(빠르게)

I - Independent(독립적으로)

R - Repeatable(반복 가능하게)

S - Self-Validating(자가 검증하는)

T - Timely(적시에)

 

 

 

---

느낀점

• 설계를 테스트로 검증 한다는 점이 설계에 대한 신뢰성을 더욱 올려줄 것 같습니다.
• TDD의 장점과 정의는 많지만 어떻게 해야 하는지 아직 감이 안잡히고 있습니다.
  • 이건 TDD 수업을 해주는 교육기관에서 수업을 받아야 할 것 같습니다.
• TDD는 아니더라도 테스트 코드를 성실하게 작성할 예정입니다.
  • 서비스단 메서드 하나에 하나의 테스트를 작성할 수 있도록 진행