테코톡 TDD와 단위 테스트 정리

✔︎ TDD & 단위 테스트

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

TDD(Test Driven Development)

테스트 코드 먼저! 실제 코드 나중에

• TDD 과정

  설계 → 테스트 코드 작성 → 개발

• TDD 개발 사이클

  RED → GREEN → REFACTOR

  • RED: 테스트를 실패
  • GREEN: 테스트를 성공할 수 있게 프로덕션 코드를 구현
  • REFACTOR: 프로덕션 코드와 테스트 코드를 리팩토링

• 왜? TDD

  • TDD의 장점
    • 리팩토링이 편하다.
    • 디버깅 시간을 줄여준다.
    • 동작하는 문서 역할을 한다.
  • TDD의 장점 BY 발표자
  • 테스트 커버리지가 높아진다
    • 항상 테스트 코드를 먼저 작성하게 되니 테스트 커버러지가 자연스럽게 높아진다
  • 오버 엔지니어링 방지
    • 필요한 만큼만 구현
    • 불필요한 노력 줄여준다..
  • 설계에 대한 빠른 피드백
    • 개발 전 테스트 코드를 통해 설계에 대한 문제 파악할 수 있다

• TDD의 오해

  • TDD는 설계 방법론?
    • TDD는 높은 응집을 유도하지 않는다
    • TDD는 SRP, OCP 위배에 대한 어떤 신호도 주지 않는다
    • TDD는 인터페이스 일관성을 도출하지 않는다
    • TDD의 리팩토링 단계는 좋은 구조를 안내하거나 좋은 구조를 갖도록 강제하지 않는다.
    • 고로 TDD는 설계 방법론이 아니다.

• TDD를 실패하는 이유?

  • TDD를 실패하는 사람의 테스트
    • 기능을 어떻게 구현하고 있는지 테스트한다
  • 구현체가 아닌 interface를 테스트 해야한다.

단위 테스트(unit test)

• 단위 테스트의 목적

  • 문제점 발견
  • 쉬운 변경
  • 품질 향상
  • 코드의 문서화 → 예외 상황, 용도, 의존 관계를 한눈에 파악할 수 있다

• FIRST

  • F: Fast, 테스트는 빨라야 한다.
  • I: Independent, 테스트는 서로 의존해서는 안된다
  • R: Repeatable, 테스트는 어떠한 환경에서도 반복 가능해야한다.(네트워크가 연결되지 않는 상황에서도 가능해야 한다)
  • S: Self-Validating, 테스트의 결과는 boolean이다. 즉 테스트의 결과는 성공 아니면 실패 뿐이다.
  • T: Timely, 테스트는 실제 코드를 구현하기 직전에 작성되어야 한다.(실제 코드 작성 후 테스트를 하게되면 실제 코드가 테스트하기 어렵다는 것을 뒤늦게 발견할지도 모른다)

출처

피카의 TDD와 단위테스트