[SpringBoot] 2장 스프링부트에서 테스트 코드를 작성하자

견고한 서비스를 만들고 싶은 개발자나 팀에서는 TDD(Test Driven Development)를 하거나 최소한 회사가 테스트 코드에 관해 요구하고 있다. 

실제로 서비스 회사의 경우 대부분 코딩 테스트를 알고리즘이 아닌 프로젝트를 만들고, 단위 테스트를 필수조건으로 두고 있다.

테스트 코드를 전혀 해보지 못했던 사람들은 모두 탈락하게 되었다.

 

 그만큼 요즘 선망받는 서비스 회사에 취업과 이직을 하기 위해서는 테스트 코드는 절대 빠질 수 없는 요소이다.

 

1. 테스트 코드 소개

 TDD와 단위 테스트(Unit Test)는 다른 이야기이다.

TDD는 테스트가 주도하는 개발을 이야기한다. 즉 테스트 코드를 먼저 작성하는 것부터 시작한다.

레드 그린 사이클

- 항상 실패하는 테스트를 먼저 작성 (Red)
- 테스트가 통과하는 프로덕션 코드를 작성 (Green)
- 테스트가 통과하면 프로덕션 코드를 리팩토링 (Refactor)

 

 반면 단위 테스트는 TDD의 첫 번째 단계인 기능 단위의 테스트 코드를 작성하는 것을 의미한다.

TDD와 달리 테스트 코드를 꼭 먼저 작성해야 하는 것도 아니고, 리팩터링도 포함되지 않는다. 순수하게 테스트 코드만 작성하는 것을 이야기한다. 

 

2. 테스트 코드는 왜 작성해야 할까?

1. 빠른 피드백

* 단위 테스트 코드를 작성함으로써 얻는 이점
 - 단위 테스트는 개발단계 초기에 문제를 발견하게 도와준다.
 - 단위 테스트는 개발자가 나중에 코드를 리팩터링 하거나 라이브러리 업그레이드 등에서 기본 기능이 올바르게 작동하는지 확인할 수 있다.  - 단위 테스트는 기능에 대한 불확실성을 감소시킬 수 있다.
 - 단위 테스트는 시스템에 대한 실제 문서를 제공한다. 즉 단위 테스트 자체가 문서로 사용할 수 있다.
   
 * 일반적인 코딩 방식
    1. 코드 작성
    2. 프로그램(tomcat)을 실행
    3. postman과 같은 API 테스트 도구로 HTTP 요청
    4. 요청 결과를 System.out.println()으로 눈으로 검증
    5. 결과가 다르면 다시 프로그램(tomcat)을 중지하고 코드를 수정

 

2~5는 매번 코드를 수정할 때마다 반복해야 한다. 
톰캣을 재시작 하는 시간은 수십초에서 1분 이상 소요되기도 하며 
수십 번씩 수정해야 하는 상황에서 아무런 코드 작업 없이 1시간 이상 
소요되기도 한다. 왜 계속 톰캣을 내렸다가 다시 실행하는가? 
테스트 코드가 없다 보니 눈과 손으로 직접 수정된 기능을 확인 
할 수 밖에 없기 때문이다.
테스트 코드를 작성하면 이런 문제가 해결되므로 굳이 손으로 직접 톰캣을 
계속 올렸다 내렸다 할 필요가 없다.

2. 자동 검증 (실행만 하면 수동 검증이 필요 없음)

 매번 System.out.println()을 통해 눈으로 검증해야 하는 문제가 있다. 테스트 코드를 작성하면 더는 사람이 눈으로 검증하지 않게 된다.

 

3.  개발자가 만든 기능을 안전하게 보호

 예를 들어 B라는 기능이 추가되어 테스트하고 기능이 잘 작동해서 오픈했더니 기존에 잘 되던 A 기능에 문제가 생긴 것을 발견했다. 이런 문제는 규모가 큰 서비스에서 빈번하게 발생하는 일이다. 하나의 기능을 추가할 때마다 너무나 많은 자원이 들기 때문에 서비스의 모든 기능을 테스트할 수는 없다.

 

4. 테스트 코드 프레임워크

 테스트 코드 작성을 도와주는 프레임워크들이 있다. 가장 대중적인 테스트 프레임워크는 xUnit이 있는데 이는 개발환경에 따라 Unit 테스트를 도와주는 도구이다.

Junit	Java
DBUnit	DB
CppUnit	C++
NUnit	.net