TDD (Test Driven Development), 테스트 주도 개발이란?

2010년에 쓰인 👉  채수원님의 TDD 실천법과 도구 공개 PDF 를 참고하였다.

 

지금까지는...

내가 지금까지 소프트웨어를 개발할 때 했던 방식은 중간중간 println 이든 congole.log 든, 혹은 logging 라이브러리든 콘솔창에 데이터를 찍어보며 코드를 검증했다. 이런 경우 자신의 머리로 대부분을 의존해야한다. 게다가 만약 기능이 추가되거나 코드의 일부분이 변경된다면? 다시 로그를 찍고 문제되는 부분을 살펴보는 작업을 반복해야 한다. 여기에 코드의 몸집이 거대해진다면? 디버깅해야하는 부분을 찾아내기 더 어려워진다. 정신차려보면 어느새 로그 찍는 코드가 비즈니스 로직만큼 적혀 있다.

 

TDD, 테스트 주도 개발

그래서 나온 것이 테스트가 주도하는 개발, TDD 다. 테스트가 주도한다는 건 함수나 모듈을 만들기 전에 테스트를 먼저 한다는 것이다. 프로덕션 코드를 작성하지도 않았는데 어떻게 테스트하지? 라는 의문을 가졌는데, 아래 설명을 보니 이해가 되었다.

 

테스트를 먼저 하라!

int a, b 를 더한 합계를 반환하는 sum 함수를 생각해보자. 정상적으로 동작했다면 sum(a,b) = (a+b) 가 true 일 것이다. 프로덕션 코드를 작성하지 않아도 어떻게 테스트할지 감이 잡힌다. sum(1,2) = 3 / sum(6, 20) = 26 이 true 인지 false 인지 검사하면 된다. 아래 코드를 참고하자.

public class Calculator {
	public int sum(int a, int b) {
		return 0;
	}

	public static void main(String[] args) {
		Calculator calc = new Calculator();
		System.out.println( calc.sum(10, 20) == 30);
		System.out.println( calc.sum(1, 2) == 3);
		System.out.println( calc.sum(-10, 20) == 10);
		System.out.println( calc.sum(0, 0) == 0);
	}
}

-----실행 결과-----
false
false
false
true

여기서는 main 메소드가 테스트 메소드처럼 사용되었다. 테스트 대상인 sum 메소드는 컴파일 에러가 나지 않는 빈 상태이다. 몸체 안을 구현하지 않고 테스트 코드를 작성했다. 각각의 테스트 코드를 테스트 케이스라고 한다. 몸체가 구현되지 않았으니 테스트 케이스들은 당연히 실패한다. 일부러 실패하는 코드를 짠 것이다.

 

테스트 케이스들은 바로 위에서 말한 종료 조건에 따른 것이다. 10+20 = 30 이 나오면 종료, -10+20=10 이 나오면 종료... 테스트 케이스를 작성했으니 이제 몸체, 실제 프로덕션 코드를 구현한다. 그리고 다시 돌렸을 때 테스트 케이스들이 모두 true 로 출력되면 sum 메소드는 정상적으로 작성됐다고 판단한다. 이후에는 테스트를 통과한 프로덕션 코드를 중복된 로직이 없는지, 쓸데없는 데이터가 들어가진 않았는지 살펴보고 리팩토링한다.

 

이렇게 메소드 단위로 하는 테스트를 단위 테스트(unit test) 라고 한다. 단위테스트를 수행함으로써 이후에 발생하는 테스트 단계에서의 결함 비용을 줄인다. 결함은 빨리 발견될 수록 적은 비용으로 처리가 가능하기 때문이다.

 

또 여기서는 println 으로 출력했지만, 이걸 자동으로 확인해주는 라이브러리들이 있으니 그걸 사용하면 된다. 따라서 개발자들은 로그를 하나하나 찍지 않아도 저렇게 테스트 케이스만 만들어두면 자동으로 테스트할 수 있는 것이다.

 

TDD 의 프로세스

위에서 살펴본 것처럼 (프로덕션 코드가 없는 빈 함수이므로) 실패하는 테스트 코드를 작성하고 -> 테스트가 통과하는 프로덕션 코드를 작성하고 -> 코드를 리팩토링하는 사이클을 레드 그린 사이클이라고 한다.

 

출처:https://trifulcas.com/tdd-desarrollo-guiado-por-pruebas/

 

 

뭐가 좋을까?

위에서 간략하게 말하고 넘어갔던 테스트 개발의 장점은 아래와 같다.

1. 개발단계 초기에 문제를 발견하게 도와준다.
2. 나중에 코드를 리팩토링하거나 라이브레이드 등 기존 기능이 올바르게 작동하는지 확인할 수 있다.
3. 단위 테스트 자체를 문서로 사용할 수 있다.

 

이제 테스트를 먼저 한다는 말이 무엇인지 이해가 되었다. 어려운 기술을 쓴 것도 아니다. 프로덕션 코드를 작성하기 전에 테스트 케이스를 먼저 작성하는 것이다!

 

진짜 간단할까?

이렇게 간단한 것처럼 말했지만, TDD 를 적용하기 어려운 상황이 많다. 특히 의존관계가 많은 모듈은 TDD 를 적용하기 어렵다... 그래서 이전에는 최소한의 테스트 코드만 작성했었는데 요즘 추세는 대부분의 서비스 회사가 테스트 코드에 관해 요구하고 있다고 한다. 코딩 테스트를 단위 테스트로 보는 경우도 있다고...

 

TDD 의 유의 사항

테스트 케이스의 이름

좋은 코드는 항상 말하지만, 사람이 읽기에도 편한 코드다. 테스트 케이스는 후에 '이런 상황에 이렇게 테스트 되고 있구나' 를 파악할 수 있는 좋은 명세서가 된다. 따라서 이름을 의미 있게 짓자.

 

케이스는 많을 수록 좋은 게 아니다

자동화된 테스트 케이스는 소스품질을 높여주지만, 그렇다고 많은 게 좋은 건 아니다. 중복된 케이스나 더 이상 제대로 동작하지 않는 케이스는 과감히 삭제하는 게 좋다. 또 모든 상황에 대한 케이스를 만들 필요도 없다. 테스트 주도 개발이라고 해서 테스트에게 주도되는 개발자가 되라는 건 아니다.  테스트는 소프트웨어가 정상적으로 동작하는지 확인을 위한 보조 도구이다.

 

여러 개의 fail 테스트 케이스를 한 번에 만들지 않는다

개발 중에는 작성하고 있는 하나의 클래스에 하나의 실패하는 테스트만 유지한다. 해당 실패를 성공시킨 후 다음 실패 케이스를 작성하는 게 좋다. (무작정 여러 개를 작성하면 당연히 좋은 테스트 코드를 쓸 수 없으니...)

 

하나의 테스트 케이스는 하나만 테스트하도록 한다.

하나의 테스트 메소드에서 하나 이상의 항목을 한꺼번에 테스트하는건 좋지 않다. getter, setter 성격 비슷하니 둘 다 테스트해! 는 바람직하지 못한 테스트다... 

 

이런 흐름을 유지하면 좋다.

시간이 걸리더라도 테스트 코드를 문맥에 맞게 잘 설계하고, 프로덕션 코드가 더렵더라도 최대한 빠르게 테스트 코드를 통과하도록 작성한 이후 리팩토링을 하는 리듬을 유지하는 걸 추천한다.