Test - TDD(테스트 주도 개발방법론)이란?

TDD(테스트 주도 개발론)이란?

 

배경

흔한 기존의 개발 방법은 위 그림과 같다. 요구사항에 따라 기능을 구현한 뒤 콘솔에 표시되는 값을 통해 간단히 확인을 한다. 그 다음 간단한 테스트를 거쳐 에러가 발생하지 않는다면 개발이 완료되었다고 생각한다. 하지만 이러한 방법은 시간이 지나고 코드의 크기가 커질수록 버그 수정에 필요한 부분을 찾아내기 어려워진다. 이러한 개발 방법의 문제점들은 아래와 같다.

1. 특정 모듈의 개발 기간이 길어질수록 개발자의 목표의식이 흐려진다

​ - 어디까지 진행했었는지

​ - 모듈이 무슨 기능을 가져야 하는지

2. 작업 분량이 늘어날 수록 테스팅이 어려워진다

​ - 로그가 어디있었는지

3. 개발자의 집중력이 필요해진다.

​ - 테스팅 하려던 화면이 지나가면 다시 처음부터 ..

4. 논리적인 오류를 찾기가 어렵다.

​ - 이 값이 들어가면 저 값이 출력되는게 맞던가 ?..

5. 코드의 사용 방법과 변경 이력을 개발자의 기억력에 의존하게 된다.

​ - 맞아! 개인 고객 인증을 수정하면 법인 고객 인증 부분도 함께 수정했어야 했어.

6. 코드 수정시 기존 코드의 정상 동작에 대한 보장이 어렵다

​ - 여길 수정하면 정상작동 하겠군 아 그런데 다른 곳에서는 이코드를 사용하지 않나?..

7. 테스트를 하려면 소스코드에 변경을 주어야 하는 등 번거로운 선행작업이 필요하다.

​ - 입고 처리 테스트를 하려면, 주문이 완료되었다라고 하기 위해 테이블에 직접 업데이트를 해줘야지 !..

 

TDD란?

프로그램을 개발하기 전에 먼저 테스트 코드를 작성하는 것. 즉, 코드를 검증하는 테스트 코드를 먼저 만든 다음에 실제 작성해야 하는 프로그램 코드 작성을 하는 것이다. 이는 "작성 되지 않은 프로그램을 어떻게 테스트하는 코드를 만드냐"라고 생각할 수 있으나 메소드 같은 모듈을 작성 시 작성 종료조건을 먼저 정해 놓고 코딩을 한다는 의미로 받아들이면 된다.

x
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);
    }
}
​
---- Result ---
false
false
false
true

위와 같이 Calculator라는 class를 작성하는 경우 sum()메소드는 에러만 내놓지 않도록 비어있는 상태이며 main() 메소드를 테스트 메소드처럼 사용하였다. sum() 메소드를 먼저 구현한 후 테스트를 할 수 있지만 그렇게 하지 않고 검증 코드를 먼저 만들어 놓았다. 즉 main() 메소드의 실행 결과가 모두 true로 나타나면 sum() 메소드가 정상적으로 개발되었다라고 판단 하기로 한것이다. 다시 말해 코드를 통해 개발 종료조건을 명시적으로 나타낸 것이다. 이러한 개발 접근 방식이 TDD이다.

 

목표

TDD를 통해 얻고자 하는 최종 목적은 잘 동작하는 깔끔한 코드(Clean Code) 이다. 이는 유지보수의 편의성, 가독성, 안정성등의 여러가지 의미를 내포한다.

 

TDD 진행 과정

xxxxxxxxxx
질문(Ask) : 테스트 작성을 통해 시스템에 질문한다.(테스트에 실패할만한 질문을 해야한다.)
응답(Response) : 테스트를 통과하는 코드를 작성해서 질문에 대답한다.
                 (테스트에 통과할 최소의 코드만을 작성해야 한다.)
정제(Refine) : 아이디어를 통합하고, 불필요한 코드를 제거하고 모호한것을 명확히한다.
반복(Repeat) : 다음 질문을 통해 계속해서 진행해 나간다.

클래스(Class) 설계시 주의할 점

보통 클래스를 설계할 때 잘못하는 점이 흔히 속성에 집중하여 설계를 하는 경향이 있다. 예를 들어 Account라는 클래스를 만들기로 결정했다면 다음에 어떤 내부 속성을 가져야 할까라는 고민을 시작한다는 것이다. 이러한 속성이 필요하지 않을까 저런 속성이 필요하지 않을까? 라는 고민을 한참 하기 마련이다. 하지만 클래스를 정의할 때 중요한건 속성이 아니라 동작이다. 따라서 동작을 먼저 정하고 동작에 필요한 속성을 고려한다는 식으로 접근해야 클래스에 불필요한 속성이 포함되는 불쌍사를 줄일 수 있다.