[TDD] 실전에서 사용해본 TDD(Test-Driven Development)

현재 회사에서 TDD 방식으로 개발중에 있습니다.

TDD를 도입한 건 현재 진행 중인 프로젝트부터라 경험이 많지는 않지만, 조금이나마 도움이 되실 분들이 있을까 해서 포스팅합니다.

사실 테스트 코드 때문에 울부짖은 적이 한두번이 아니긴 합니다만...

 

출처 : https://www.reddit.com/r/ProgrammerHumor/comments/11164wl/tdd_is_super_important_and_useful/

앗... 위 짤은 무시하셔도 됩니다.^^

 

TDD란?

이 포스팅을 보실 정도면 대충 TDD가 어떤 것인지에 대해서는 알고 계시겠지만 간략하게 개념을 설명하고 넘어가자면, TDD는 Test Driven Development(테스트 주도 개발)의 약자입니다.

 

코드의 전반적인 설계를 테스트 코드로 한다는 건데, 쉽게 말해서 테스트 코드를 먼저 작성하고 그 테스트를 통과하도록 소스 코드를 짜면 됩니다.

TDD를 도입하기 전까지 기존의 방식은, 소스 코드를 먼저 작성하고 그 기능이 잘 돌아가는지 확인하기 위해 테스트 코드를 짜는 것이었죠.

 

제가 팀원들과 협업을 하면서 느낀 TDD의 장점은,

1. 요구사항에 부합하는 코드를 작성할 때의 지표가 되어줌

2. 다른 사람의 코드를 읽을 때 테스트 코드에 설명된 내용을 보고 그 코드에 대해 한눈에 파악이 가능하다는 점

3. 가끔 진짜로 테스트 코드 덕분에 버그 발견함

정도라고 할 수 있겠네요.

 

단점은 모두 아시겠지만 숙달되기까지 시간이 좀 걸립니다...

 

TDD 순서

TDD는 다음과 같은 순서로 이루어집니다. (제 사족이 좀 들어갔습니다...)

 

0. 테스트에 필요한 메소드의 껍데기와 객체 등은 미리 만들어 놓는다.

@Service
public class HelloService {
    public String hello(HelloDto helloDto) {
        return "Hello";
    }
}

이런 형태의 메소드를 테스트한다고 칩시다.

로직은 없어도 되지만, 적어도 hello()라는 메소드와 파라미터에 쓰인 HelloDto라는 객체는 미리 만들어 놓아야겠지요.

그래야 테스트 코드에서 Hello라는 메소드를 실행할 수 있으니까요.

 

1. 실패하는 테스트 코드를 작성한다.

여기서 유의해야 할 점은 오류가 아닌 실패가 나와야 합니다.

예를 들어, 무조건 200이 반환되어야 하는 로직의 메소드를 검증하는 테스트 코드가 있다고 합시다.

실패하는 테스트 코드는 검증 부분에서 "결과값이 200이 아닙니다" 라는 결과가 나와줘야 합니다.

반면 오류는 테스트 코드 자체에 결함이 있어 검증을 하기도 전에 에러를 뱉어내며 종료되는 경우라고 볼 수 있죠.

 

2. 테스트 코드를 성공시키기 위한 소스 코드를 작성한다.

이 단계에서 정말 극단적으로는 로직 없이 바로 200을 반환해버리는 코드를 작성하기도 하더군요.

경우에 따라 다르겠지만 저희 팀 같은 경우엔 바로 로직을 짭니다.

 

3. 코드를 리팩토링한다.

테스트 코드를 통과만 하도록 소스 코드를 짰다면 좀 더 정리할 부분이 있을 수 있습니다.

중복을 제거하고, 가독성이 좋도록 코드를 수정하는 작업이 필요하겠죠.

 

이 과정을 반복합니다.

하나의 기능에 대해 모두 테스트 코드를 짜 놓고(몇 가지가 될 수 있겠죠), 다음으로 그 기능에 대한 개발에 들어가면 됩니다.

예를 들어 프로필을 조회하는 기능인데, 회원 여부에 따라 출력값이 변해야 한다는 조건이 있다고 합시다.

그렇다면 1. 회원일 경우, 2. 비회원일 경우 이렇게 두 가지의 테스트 코드를 짜면 됩니다.

 

 

다음 포스팅에서는 Junit을 통해 TDD를 직접 구현해보도록 하겠습니다.