TDD의 개념
TDD는 매우 짧은 개발 사이클을 반복하는 software 개발 프로세스 중 하나이다.
TDD와 기존 개발 프로세스의 차이점
TDD의 3가지 절차
Red(실패): Writing a Failing test
TDD 개발에서의 첫번째 단계는 실패이다. 즉 실패하는 테스트 케이스를 작성하는 것이다. 이때 테스트케이스는 프로젝트 전체의 모든 기능에 대해서 모든 케이스를 작성하는 것이 아니라, 먼저 구현할 기능에 대새서 테스트 케이스를 하나씩 작성해 나가는 것이다.
Green(성공): Write just enough code to pass it
두번째 단계는 성공이다. 실패 단계에서 작성한 테스트 케이스를 통과 시키기 위한 최소한의 코드를 작성하는 단계이다.
Blue(리팩토링): Change code for better without chaning the behavior
세번째 단계는 리팩토링이다. 성공단계에서 작성한 코드에 중복되는 코드나, 개선시킬 방법이 있다면 리팩토링을 진행해둔자. 리팩토링을 진행하면서 매 단계마다 테스트 케이스를 통과하는지 확인해야한다. 이 단계까지 구현이 완료되었다면 다시 첫번째 단계로 새로운 실패하는 테스트 케이스를 작성하면 된다.
TDD의 장점
-
객체지향적인 코드 개발
테스트 코드를 먼저 작성하면 명확한 기능과 구조를 설계할 수 있다. 또한 TDD프로세스를 따르는 코드의 경우에는 재사용성을 고려하며 작성하게 된다.
-
설계 수정 시간의 단축
테스트를 먼저 해보기 때문에 걸계의 구조적인 문제를 바로 찾아날 수 있게 된다.
-
디버깅 시간의 단축
단위 테스트 기반의 테스트 코드를 작성 → 문제 지점을 쉽게 발견
-
유지 보수의 용이성
자동화된 유닛 테스팅을 전재 → 테스트 기간 ↘️
-
테스트 문서의 대체 가능
테스팅을 자동화 && 테스트의 근거를 산출할 수 있다.
단위테스트(Unit Test)
단위테스트(Unit Test)는 컴퓨터 프로그래밍에서 소스 코드의 특정 모듈이 의도된 대로 정확히 작동하는지 검증하는 절차이다.
단위테스트 장점
- 문제점 발견 → 프로그램의 각 모듈들을 고립시켜서 각각의 부분들이 정확하게 동작하는지 확인하는 것이다.
- 변경이 쉽다 → ****Unit Test를 믿고 regectoring을 언제든지 할 수 있고, 변경후에 해당 모듈이 잘 작동하는지 확인하는 unit test인 회귀 테스트를 통해서 변경된 모듈을 확인할 수 있다.
- 통합이 간단 → 유닛 자체의 불확실성을 제거해주므로 bottom-up(상향식) 테스트 방식에서 유용하다. 각 모듈을 검증하고 모듈들을 합쳐서 다시 검증하는 통합 테스트에서 더욱 효율적이다.
단위테스트는 어떻게 작성해야할까?
FIRST - 테스트에 대한 모법 사례(Best Pracices for testing)
- Fast(빠르게) : 테스트는 빠르게 실행되어야 한다.
- Isolated / Independent(분리된 / 독립적인) : 테스트는 따로 설정이나 분리를 해서는 안된다.
- Repeatable(반복가능한) : 테스트 수행할 때 마다 동일한 결과를 얻어야 한다. 외부의 데이터 공급자나 동시성 문제로 인해 일시적 오류는 발생할 수 있다.
- Self-validating(자체 검증) : 테스트는 완전히 자동화 되어야 한다. 로그 파일에 대한 프로그램의 해석보단 “pass” or “fail” 출력
- Timely(적시에) : 이상적인 테스트는 테스트한 생산 코드를 작성하기 전에 작성해야한다.
단위테스트는 무엇을 테스트 해야할까?
Right - BICEP
Right - 결과가 올바른가?
- Boundary : 모든 경계 조건이 correct 한가? (경계값들의 조건)
- Inverse : 역 관계를 확인할 수 있는가?
- Cross-Check : 다른 수단을 사용해서 결과를 교차할 수 있나?
- Error Condition : 에러 조건을 강제로 만들 수 있나?
- Performance : 성능 특성이 한도내에 있나?
이상 공부 끝
