[10분 테코톡] 😼 피카의 TDD와 단위테스트 정리

TDD (Test-Driven Development) 란?

테스트 코드를 먼저 만들고, 실제 프로덕션 코드를 나중에 만드는 개발 방법

 

위 그림과 같이 기존 개발 프로세스는 설계, 개발, 테스트코드 작성 순서였다면 TDD는 개발 코드 작성보다는 테스트 코드를 먼저 작성하는 개발 방법 이다.

 

위 그림은 TDD 개발 사이클을 그림으로 나타낸 것이다.

먼저 RED : 테스트를 실패하고

Green : 테스트를 성공할 수 있게 프로덕션 코드를 구현한 후

Refactor : 프로덕션 코드와 테스트 코드를 리팩토링하는

세가지 사이클로 이루어져 있다.

 

 

왜 TDD를 만들었고 왜 사용할까?

 

TDD를 사용하는 이유?

- 변화에 대한 두려움을 줄여준다.(리팩토링이 편하다.)

- 디버깅 시간을 줄여준다.

- 동작하는 문서 역할을 한다.

 

TDD 장점

1) TDD를 하면 자연스레 테스트 커버리지가 높아진다.

물로 테스트 커버리지가 높다고 해서 무조건 좋은 코드는 아니다. TDD를 사용하면 테스트 코드를 먼저 작성하니 자연스레 테스트 커버리지가 높아진다.

 

2) 오버 엔지니어링 방지

요구사항에 맞추어 개발 코드를 구현하니 정말 필요한 만큼만 코딩할 수 있다. 미래의 필요할 것 같은 구현을 지레 짐작하여 불필요한 코드를 작성하게 되면 이는 오버엔지니어링 이라고 할 수 있다. TDD는 이런 점을 방지해 준다.

 

3) 설계에 대한 피드백이 빠르다.

설계를 잘못 했다면 언제 깨달을 수 있을까? 변경이 일어나거나 사용하기 어려울 때 깨달을 수 있다. 예를 들어 테스트 코드를 작성하는데 복잡하고 잘못된 설계를 가지고 있으면 새로운 테스트 코드를 작성하기가 점점 더 어려워 질것이다. 그러면 빠르게 설계를 바꾸면 된다.

 

TDD의 오해

TDD는 설계방법론이다?

TDD가 설계 방법론이라면 TDD를 통해 좋은 설계를 얻을 수 있어야 할 것이지만 아래와 같은 이유로 설계 방법론이 아니다라는 것을 증명해주고 있다.

- TDD는 높은 응집을 유도하지 않는다.

- TDD는 단일 책임 원칙과 인터페이스 분리 원칙 위배에 어떤 신호도 주지 않는다.

- TDD는 인터페이스 일관성을 도출하지 않는다.

- TDD의 리팩토링 단계는 좋은 구조를 안내하거나 좋은 구조를 갖도록 강제하지 않는다.

 

물론 TDD가 설계에 전형 영향을 미치지 않는 것은 아니다. TDD는 강한 결합과 의존성역전 원칙위배를 경고하고 불명확한 설계 지점을 발견해주기도 한다. 하지만 전적으로 TDD에만 설계를 의존하게 된다면 테스트 하기만 좋은, 결국 안 좋은 설계가 만들어진다.

 

TDD를 실패하는 이유?

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

출처 : [OKKYCON: 2018] 이규원 - 당신들의 TDD가 실패하는 이유

 

위 화살표를 보면 테스트들이 구현체 안에 있는 Implementation 내부에 존재하는 구현체들을 테스트하고 있다.

 

만약 Implementation을 리팩토링하게 되면 테스트들이 모두 깨지게 된다. 결국 구현체가 아닌 설계 즉, 인터페이스를 테스트 해야한다. 인터페이스를 테스트하게 되면 내부에 구현되어 있는 구현체를 아무리 리팩토링 하더라도 테스트 케이스는 인터페이스를 테스트하기 때문에 테스트 케이스는 깨지지 않는다.

 

테스트의 범위

 

단위 테스트

- 가장 작은 단위 테스트

- 일반적인 메서드 레벨

- 검증이 필요한 코드에 대해 테스트 케이스를 작성하는 절차 또는 프로세스

- Unit Testing은 테스트 코드가 목적 코드의 완전성을 입증 해주기 때문에, 테스트 코드 그 자체만으로 주요한 가치가 있음

 

단위 테스트 목적

- 문제점 발견

- 쉬운 변경

- 품질 향상

- 코드의 문서화

 

좋은 단위 테스트

F - Fast(빠르게)

I - Independent(독립적으로)

R - Repeatable(반복 가능하게)

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

T - Timely(적시에)

---

참고

https://www.youtube.com/watch?v=3LMmPXoGI9Q&ab_channel=%EC%9A%B0%EC%95%84%ED%95%9C%ED%85%8C%ED%81%AC