:: TDD (Test Driven Developement)란?
반복 테스트를 이용한 SW 방법론으로, 단위 테스트(Unit Test)를 통해
테스트 케이스를 작성하면서 코드를 추가하는 반복 작업으로,
실제 프로덕션 코드를 작성하기 전 테스트 코드를 먼저 만들고 테스트하는 개발 방법
:: TDD 개발 주기
< TDD 개발 주기를 표현하는 그림 >
- Red : 실패하는 테스트를 먼저 구현
- Green : 테스트 코드를 성공시키기 위한 프로덕션 코드를 구현
- Blue : 중복 코드를 제거 , 테스트 코드 && 프로덕션 코드 리팩토링
:: TDD의 장점
-
재설계 시간 단축 (리팩토링이 편함)
-
디버깅 시간의 단축
-
테스트 문서의 대체 가능 (동작하는 문서 역활)
-
테스트 커버리지 상승
-
오버 엔지니어링 방지
-
설계에 대한 즉각적인 피드백
:: 단위 테스트 (Unit Test)란?
-
가장 작은 단위의 테스트 (일반적으로 Class, 메서드 레벨)
-
검증이 필요한 코드에 대해 테스트 케이스를 작성하는 절차 또는 프로세스
:: 단위 테스트 (Unit Test)의 장점
-
문제점을 빨리 찾아낼 수 있음
-
프로그램의 안전성을 높혀줌
-
간편하게 수정 가능
-
품질 향상 (하나의 테스트에서 너무 많은 기능을 수행한다면 리팩토링 여부 확인 가능)
:: TDD 방식 정리
TDD 방식과 일반적인 개발 방식의 차이점은 TDD는 테스트 코드를 먼저 작성한 뒤 프로덕션 코드를 작성하여 개발을 진행하는 것
설계 단계에서 목적을 미리 정의하고, 어떤 것을 테스트 해야할지 테스트 케이스를 작성해야 한다.
테스트 코드를 작성하는 도중 발생하는 예외 사항(버그 및 수정사항)은
테스트 케이스에 추가하고 설계를 개선한다.
이후 테스트가 통과된 코드만을 코드 개발 단계에서 실제 코드로 작성한다.
이러한 반복적인 단계가 진행되면서 자연스럽게 코드의 버그가 줄어들고 소스코드는 간결해진다.
또한 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로 재설계 시간이 절감된다.
후기
오늘 수업에서 TDD (Test Driven Development) 가 무엇이며, 어떻게 사용하는가?
라는 부분에 대해서 배웠고, 실습을 해 봤다.
솔직히 말하면 강사님이 진행을 하시는데 하나도 이해를 하지 못 했고
아무래도 요인은 일단 생소함, 테스트를 하는 목적의 불분명성 같은 이유로
테스트를 하는 이유를 제대로 알지 못하고 바로 실전으로 가다보니
이해를 하지 못 했던 것 같다.
따로 복습을 하기 위해 끝나고 TDD (Test Driven Development)에 대하여 더 찾아봤고,
왜 사용을 하는지에 대해 이론적인 부분으로는 이해를 했지만
여전히 실제 코드를 이용해서 테스트 작업을 해 보는 방법은 이해하기가 어려웠다.
일단, 강사님이 강의하는 관련 내용들을 계속 돌려보고 복습해보면서
테스트 방식에 대하여 익숙해지는 과정을 먼저 익혀보자.
