CHAPTER 02 스프링 부트에서 테스트 코드를 작성하자

2.1 테스트 코드 소개

TDD

- 테스트가 주도하는 개발

- 테스트 코드를 먼저 작성하는 것부터 시작

 

레드 그린 사이클

- Red : 항상 실패하는 테스트를 먼저 작성하고

- Green : 테스트가 통과하는 프로덕션 코드를 작성하고

- Refactor : 테스트가 통과하면 프로덕션 코드를 리팩토링합니다.

 

단위 테스트

- TDD의 첫 번째 단계인 기능 단위의 테스트 코드를 작성하는 것

- TDD와 달리 테스트 코드를 꼭 먼저 작성해야 하는 것도 아니고,

- 리팩토링도 포함되지 않는다

- 순수하게 테스트 코드만 작성하는 것

 

테스트 코드를 작성함으로써 얻는 이점

- 단위 테스트는 개발단계 초기에 문제를 발견하게 도와줍니다.

- 단위 테스트는 개발자가 나중에 코드를 리팩토링하거나 라이브러리 업그레이드 등에서 기존 기능이 올바르게 작동하는지 확인할 수 있습니다(예, 회귀 테스트).

- 단위 테스트는 기능에 대한 불확실성을 감소시킬 수 있습니다.

- 단위 테스트는 시스템에 대한 실제 문서를 제공합니다. 즉, 단위 테스트 자체가 문서로 사용할 수 있습니다.

 

테스트 코드를 작성해야 하는 이유

- 빠른 피드백

1. 코드를 작성하고

2. 프로그램(Tomcat)을 실행한 뒤

3. Postman과 같은 API 테스트 도구로 HTTP 요청하고

4. 요청 결과를 System.out.println()으로 눈으로 검증합니다.

5. 결과가 다르면 다시 프로그램(Tomcat)을 중지하고 코드를 수정합니다.

여기서 2. ~ 5.는 매번 코드를 수정할 때마다 반복

왜 계속 톰캣을 내렸다가 다시 실행하는 일을 반복할까?

이는 테스트 코드가 없다 보니 눈과 손으로 직접 수정된 기능을 확인할 수밖에 없기 때문이다.

테스트 코드를 작성하면 이런 문제가 해결되므로 굳이 순으로 직접 톰캣을 계속 올렸다 내렸다 할 필요가 없다.

- System.out.println()을 통해 눈으로 검증해야 하는 문제

테스트 코드를 작성하면 더는 사람이 눈으로 검증하지 않게 자동검증이 가능하다.

작성된 단위 테스트를 실행만 하면 더는 수동검증은 필요없게 되는 것이다.

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

B라는 기능이 추가되어 테스트한다.

B 기능이 잘 되어 오픈했더니 기존에 잘되던 A 기능에 문제가 생긴 것을 발견한다.

이런 문제는 규모가 큰 서비스에서는 빈번하게 발생하는 일이다.

하나의 기능을 추가할 때마다 너무나 많은 자원이 들기 때문에 서비스의 모든 기능을 테스트할 수는 없다.

이렇게 새로운 기능이 추가될 때, 기존 기능이 잘 작동되는 것을 보장해 주는 거싱 테스트 코드이다.

A라는 기존 기능에 기본 기능을 비롯해 여러 경우를 모두 테스트 코드로 구현해 놓았다면 테스트 코드를 수행만 하면 문제를 조기에 찾을 수 있다.

 

테스트 코드 작성을 도와주는 프레임워크들

xUnit : 가장 대중적인 테스트 프레임워크, 개발환경(x)에 따라 Unit 테스트를 도와주는 도구

 

대표적인 xUnit 프레임워크들

- JUnit - Java

- DBUnit - DB

- CppUnit - C++

- NUnit - .net

 

이 중에서 자바용인 JUnit4를 사용