TDD
Test Driven Development. 즉 테스트 중심의 개발 방법론을 의미한다.
그 중에서도 자동 테스트를 전제로 한다
TDD의 필요성
소프트웨어의 품질 유지를 위해선 꾸준한 테스트가 필수적이다.
기능의 추가, 변경, 삭제가 일어날 때마다 전체 코드에 미치는 영향을 고려하지 않을 수 없기에 전체 테스트가 요구된다.
이러한 수동 테스트 과정은 매우매우 많은 시간과 인적 리소스를 요구한다.
이를 개선하기 위해 JUnit 등의 자동 테스트 툴이 대두됐다.
| 구분 | 자동 테스트 | 수동 테스트 |
|---|---|---|
| 실행 주체 | 컴퓨터 | 사람 |
| 실행 속도 | 빠름 | 느림 |
| 실행 비용 | 낮음 | 높음 |
| 신뢰도 | 높음 | 낮음 |
| 유지보수 | 용이 | 어려움 |
| 반복성 | 좋음 | 나쁨 |
| 피로도 | 없음 | 높음 |
위 표처럼 자동 테스트는 수동 테스트에 비교했을 때 압도적인 퍼포먼스를 보인다.
자동 테스트가 보편화 된 후로, 다른 방식의 개발 방법론이 제한됐는데,
기존에 선개발 후테스트의 체제를 거꾸로 시행하는 것이다.
즉, 먼저 테스트 케이스들을 늘어놓고, 해당 테스트 케이스를 만족하게 프로그램을 작성하는 것.
이를 TDD라고 부른다.
TDD 방법론은 오늘날에 와서 보편적으로 사용되며, 특히 애자일 프로세스의 핵심이다.
애자일 프로세스의 짧고 반복적인 스프린트, 유저 피드백, 점진적 개발 전부가 자동 테스트가 정상적으로 돌아가고 이에 따른 개발이 가능하다는 것을 전제 하에 실행되기에, TDD는 애자일 프로세스의 중심적인 로직이다.
대부분의 현장에서 애자일 프로세스가 선호되는 만큼, TDD 역시 산업 표준이라 볼 수 있다.
단위 테스트
해당 단락에선 툴을 활용한 자동 테스트에 대해 서술한다.
용어
| 테스트 케이스(Test Cst) | 특정 기능이나 요구사항을 검증하기 위한 테스트 시나리오 |
|---|---|
| 단위 테스트(Unit Test) | 코드의 가장 작은 단위(메서드, 클래스 등)를 독립적으로 테스트 |
| 통합 테스트(Integration Test) | 여러 컴포넌트가 함께 동작하는 것을 테스트 |
| 기능 테스트(Functional Test) | 소프트웨어의 특정 기능 혹은 동작을 테스트 |
| 회귀 테스트(Regression Test) | 기존 기능이 새로운 변경사항으로 인해 깨지지 않았는지 확인하는 테스트 |
| 테스트 커버리지(Test Coverage) | 테스트가 얼마나 많은 코드를 실행했는지를 나타내는 지표 |
| 테스트 더블(Test Doubles) | 테스트를 위해 실제 객체 대신 사용하는 가짜 객체 (Mock, Stub, Spy 등) |
| 리팩토링(Refactoring) | 코드의 기능은 유지하면서 내부 구조를 개선하는 작업 |
필요성
- 코드에 대해 수시로 빠르게 검증을 받을 수 있다 (특히 기능의 추가, 수정, 삭제 등의 상황에서)
- 유지보수 및 리팩토링의 안정성을 확보할 수 있다
- 개발 및 테스팅에 대한 시간과 비용을 절감할 수 있다
좋은 테스트의 특징(FIRST 규칙)
- Fast: 테스트는 빠르게 동작하여 자주 돌릴 수 있어야 한다.
- Independent: 각각의 테스트는 독립적이며 서로 의존해서는 안된다.
- Repeatable: 어느 환경에서도 반복 가능해야 한다.
- Self-Validating: 테스트는 성공 또는 실패로 bool 값으로 결과를 내어 자체적으로 검증되어야 한다.
- Timely: 테스트는 적시에 즉, 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다
TDD 3단계(RGB)
1. Red : 실패하는 테스트 작성
- 구현하려는 기능에 대한 테스트 코드를 먼저 작성한다
- 현 단계에선 테스트가 실패하는 것이 정상이다
2. Green : 테스트를 통과하는 최소한의 코드를 작성
- 코드 품질이나 최적화는 고려하지 않는다
3. Refactor : 코드 개선
- 테스트가 통과하는 상태를 유지하며 코드를 개선한다
- 중복 제거, 가독성 향상, 성능 최적화 등을 수행한다.
기능이 충분히 완성될 때까지 위 3단계를 반복한다.
세부 구현 방법
가짜로 구현하기
- 아무 값이나 반환하도록 구현한다
- 주로 정해진 상수를 반환하도록 한다
- 가장 빨리 테스트를 통과하는 방법이다
- 복잡한 코드의 경우, 단계를 잘게 쪼개서 개발할 수 있다
삼각측량법
- 테스트 주도로 추상화된 과정을 일반화한다
- 즉, 복수 개의 테스트 케이스에서 일반화된 로직을 끌어낸다
명백하게 구현하기
- 위 두 방법을 사용하지 않고 바로 정답을 구현한다
- 간단한 문제의 경우 바로 진짜 구현을 해도 괜찮다.
장점
- 테스트 케이스의 모음을 통해 기능을 구성하는 로직의 패턴을 찾을 수 있다 (삼각측량법)
- Test Case를 쌓아가면서 안정적으로 개발할 수 있다
- 깔끔한 코드를 작성할 수 있다
- 장기적으로 개발 비용을 절감할 수 있다
Dynamic Programming을 통해 문제를 해결할 때, 점화식을 찾기 위해 여러 case를 늘어놓고 insight를 얻는데, 이러한 과정과 유사하다.
이런 장점 덕분에 개발 시간을 줄여주고 품질 향상에 기여할 수 있다.
