JAVA]TDD(Test Driven Develop) 테스트 주도 개발

개벌을 해가면서 점점 개발 방법론에 대한 이야기를 많이 듣는다.

 

오늘은 MSA에 이어 가장 많이 들었던 개발 방법론인  TDD에 대해 소개한다.

 

일단 TDD는 타이틀에서도 알 수 있듯이, 선 테스트 후 개발이다.

 

 

이 말이 무슨 말이냐면, 일반적인 개발 순서를 떠올리면 이해가 쉽다.

 

예를 들어, 웹 개발을 한다고 가정해보자.

 

 

/login으로 GET 요청이 오게 되면 Login의 view페이지를 리턴해주는 메서드가 있다고 가정하면, 

 

이 메서드를 다 정의 해놓고 나서

ID나 PW에 여러 값들을 넣어보면서 값에 대한 유효성 체크라던지 등등의 기타 에러나 버그가 일어날지 체크한다.

 

보통의 개발 순서와 다르지 않다.

 

위와 같은 과정을 거치게 되면 

 

다 완성 후, 테스트를 하기 때문에 버그가 발생하거나 에러 발생 시 연관된 수많은 코드를 고쳐야 할 상황이 생길 수 있다.

 

이는 최소 결합,최대 응집(모듈화)이 중요한 이유기도 하다. 

 

 

이런 문제를 해결하기 위해, 개발의 순서를 바꿔 선 테스트 후 개발을 하는 방법이 TDD이다.

 

선 테스트를 한다는게 어찌 보면 굉장히 추상적인 이야기가 될 수 있는데, 

이에 대한 예시를 드는데는 어렵지 않다. 

 

혹시, 프로그래머스, 백준 등과 같은 알고리즘 사이트에서 문제를 풀어본 적이 있다면 쉽게 알 수 있다.

 

이런 문제 설명들이 있고, 예시를 몇 개 들어준다. 

그리고 다 문제를 풀고 제출을 누르게 되면

아래와 같은 화면이 뜨면서 첫 번째 이미지의 입출력 예시처럼 다양한 값들에 대해 코드가 똑같은 기능을 하는지 테스트한다.

 

이것이 TDD의 개발 방법론과 일맥상통한다고 볼 수 있다.

 

 

순서를 정리해보면

1.API의 요구조건에 대한 파악

2.요구 조건에 대한 샘플 테스트 케이스 1~2가지를 목표로 코드 작성

3. 샘플 이외에 다른 케이스의 값을 넣어보며 다른 Input에 대한 동일한 과정으로 Output을 만들어 내는지 체크

 

이 과정을 테스트한다고 보면 된다.

전형적인 Bottom Up 방식이다. (작은 것 부터 큰 것으로 가는 방법)

 

이런 방법으로 케이스에 대한 범위를 좁혀가며

애초에 기획했던 API와 개발자가 코드를 짜며 생각한 API의 기능이 얼마나 일맥상통하는지 확인하고 

둘 사이의 갭을 줄여 나가는 것이 TDD의 이유이다. 

 

이 개발 방법론을 적용하게 되면 단순하게 개발 시간은 당장 늘어난다는 단점이 있지만,

 

버그에 대한 우려가 줄어든다는 점과 후에 유지보수에 대한 용이성이 굉장히 큰 장점이다. 

 

하지만 업무의 속도가 중요하다거나

빠르게 일 처리를 해야하는 일이 있다면 이러한 개발 방법론을 적용하기는 쉽지 않겠지만 

가급적 프로젝트를 설계하는 단계나 중요한 API가 있다면 추 후에 적용하여 게시글을 추가하도록 한다.