[Spring Boot] TDD(Test-Driven-Development) (2/5)

TDD (Test-Driven-Development)

---

왜 테스트 코드를 먼저 짜는 거야? 코드 짜고 그 뒤에 짜도 되지 않아?

 

TDD의 기대 효과와 개발 사이클에 대해 알아보자.

 

 

TDD 기대 효과

---

생산성 향상

 

1. 계획

 테스트 코드를 짜기 위해 목적이 무엇인지, 어떤 출력 값을 기대하는지, 어떤 입력값을 받을 것인지 등등 요구사항에 대해 확실히 파악해야만 한다. TDD 방식에서 테스트 코드는 계획서, 설계도면으로 볼 수 있다. 요구사항에 맞게 계획하고 애플리케이션 코드를 구현하고 테스트를 실행 시는 체계적인 프로세스로 생산성 향상에 도움이 된다.

 

2. 반복적인 검증

 디버깅, 작동 테스트를 위해 애플리케이션을 직접 실행하는 것보다 테스트 코드를 실행하여 테스트 시간을 단축할 수 있다. 또한 리팩토링 후 테스트 코드를 실행해 반복적으로 검증할 수 있어 코드의 신뢰도가 높아진다.

 작은 토이 프로젝트의 경우 TDD 방식으로 개발 시 애플리케이션을 한 번도 실행하지 않고 완성할 수도 있다고 한다... 

 

+ 테스트 케이스 누적

 애플리케이션 코드를 작성하고 테스트 코드를 짜면 경험상 테스트 케이스 수가 적다. 직접 실행하여 잘 작동하는 것을 눈으로 보니 테스트 코드 작성에 소홀해진다. 이 상태에서 리팩토링이 필요해지면 막막하다. 코드가 꼬일까 봐 두렵다.

 

 

 

TDD 사이클

---

1. 테스트 코드를 작성한다.

     * 컴파일 에러가 발생하는 것이 정상이다. 어떤 입력값을 받을 것이고 어떤 출력 값을 기대하는지 계획한다고 생각하자.

 

2. 테스트 코드가 통과하도록 애플리케이션 코드를 작성한다.

 

3. 애플리케이션 코드를 리팩토링(클린 코드)한다.

 

4. 테스트 코드를 실행한다.

 

반복...

 

 

 

TDD 예시

---

TDD 연습을 위해 간단한 사각형 넓이 계산기를 만들어 보자.

 

1. 테스트 코드 작성

//given

가로, 세로 변의 길이를 각각 X, Y로 선언해주고, 기댓값 EXPECTED를 선언해준다.

 

//when

테스트할 메서드의 결괏값을 result에 담는다.

 

//then

기대값 EXPECTED와 result를 비교한다.

 

어떤 값이 입력되어야 하는지, 어떤 메서드를 실행시켜 어떤 결괏값이 반환되는지 큰 틀을 설계한다.

 

 실제 실행되는 코드를 작성하지 않고 테스트 코드를 작성하기 때문에 컴파일 에러가 뜬다. 괜찮다. 이 불쾌한 빨간 글씨를 없애고 정상 작동하게 만드는 과정이 TDD 이니까.

 

2. 애플리케이션 코드 작성

테스트 코드가 통과할 수 있는 애플리케이션 코드를 작성한다.

 

3. 테스트 실행

테스트에 실패하면 다시 애플리케이션 코드를 수정한다.

위 그림처럼 테스트에 통과하면 리팩토링을 수행한다.

 

4. 리팩토링

리팩토링 후 테스트를 실행시켜 정상 작동하는지 확인한다.

 

IllegalArgumentException 테스트는 따로 작성하지 않고 한 번에 처리했지만 위 과정처럼 어떤 값이 들어오고 어떤 메서드를 실행시켰을 때 어떤 예외가 발생하게 할 것인지 테스트 코드를 작성하고, 애플리케이션에 구현하는 과정을 거치면 된다.

 

이후에 코드 수정이나 기능을 추가할 때도 테스트 코드를 먼저 작성하고(설계해주고) 본 코드를 작성해주고 테스트해주면 되겠다.