TDD (Test Driven Development)
TDD는 "테스트 주도 개발" 방법론이다. 소프트웨어를 개발하면서 요구사항에 맞는 기능들을 바로 구현하는 것이 아니라, 테스트 케이스들을 만들며 개발하는 방법이다.
TDD의 단계
TDD는 레드, 그린, 블루 3개의 단계를 거친다.
1. 레드
첫번째 레드는 테스트 케이스를 만드는 단계이다. 아직 기능이 구현되지 않았기 때문에 이 테스트 케이스는 당연히 실패하게 되는데, 이때 나오는 오류들 때문에 레드라는 이름이 붙었다.
2. 그린
다음으로는 작성한 테스트 케이스가 통과되도록 기능을 만드는 것이다. 이때 최대한 간단하게 테스트 케이스에만 맞는 기능을 만든다.
전체 기능은 자연스럽게 테스트 케이스들을 만들고 통과시키면서 구현되는 것이다.
3. 블루
여기서는 그린 단계에서 작성한 코드들을 리펙토링한다. 기능을 위한 코드들 뿐만 아니라 테스트 케이스도 리펙토링의 대상이 된다.
TDD의 장단점
TDD는 소프트웨어가 요구사항을 정확하게 지킬 수 있게 하고, 오류를 조기에 발견할 수 있게 한다. 또한 계속해서 테스트를 실행하며 새로운 기능과 리펙토링이 기존 기능에 영향을 미치지 않는다는 것을 확인하며, 개발이 잘 되고 있다는 확신을 가질 수 있게 한다.
하지만 기존의 습관을 바꾸는 것이 쉽지 않고, 테스트 케이스를 작성하는 과정에서 초기 개발 시간이 길어질 수 있다는 것이 부담이 될 수 있다.
TDD의 예시
먼저 테스트 케이스를 만든다. 아래는 간단하게 run() 을 실행하면 1을 반환하는지 확인하는 테스트 코드이다.
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import static com.ll.Main.run;
import static org.assertj.core.api.Assertions.assertThat;
public class test {
@Test
@DisplayName("테스트 생성")
public void t1() {
int rs = run();
assertThat(rs).isEqualTo(1);
}
}
다음으로 그린, 테스트 케이스가 성공하게 하는 코드를 작성한다.
class Main {
public static void main(String[] args) {
}
public static int run(){
return 1;
}
}테스트 케이스가 성공했으니 다음 블루, 리펙토링 단계로 넘어가고 다음 테스트 케이스를 작성한다.
간단한 소프트웨어는 어떻게 만들던 중요하지 않지만, 기능이 많아지고 복잡해질 수록 방향을 제시하고 길을 잃지 않게 해줄 방법론이 중요한 것 같다.
