4. 스프링부트에서 테스트 코드를 작성하자

TDD 

- 테스트가 주도하는 개발

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

단위 테스트(Unit Test)

- 기능 단위의 테스트 코드를 작성하는 것을 이야기한다.

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

 

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

• 단위 테스트는 개발 단계 초기에 문제를 발견하게 도와줍니다.
• 단위 테스트는 개발자가 나중에 코드를 리팩토링하거나 라이브러리 업그레이드 등에서 기존 기능이 올바르게 작동하는지 확인할 수 있습니다.(예, 회귀 테스트).
• 단위 테스트는 기능에 대한 불확실성을 감소시킬 수 있습니다.
• 단위 테스트는 시스템에 대한 실제 문서를 제공합니다. 즉, 단위 테스트 자체가 문서로 사용할 수 있습니다.

---

이 책의 작성자가 단위 테스트를 배우기 전에 진행한 개발 방식은 다음과 같습니다.

1. 코드를 작성하고
2. 프로그램(Tomcat)을 실행한 뒤
3. Postman과 같은 API 테스트 도구로 HTTP 요청하고
4. 요청 결과를 System.out.println()으로 눈으로 검증한다.
5. 결과가 다르면 다시 프로그램(Tomcat)을 중지하고 코드를 수정합니다.

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

- 톰캣을 재시작하는 시간은 수십 초에서 1분 이상 소요되기도 하며 수십 번씩 수정해야만 한다.

 

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

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

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

 

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

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

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

 

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

- B라는 기능이 추가되어 테스트합니다. B기능이 잘 되어 오픈했더니 잘 되던 A기능에 문제가 생긴 것을 발견

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

---

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

 

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

- xUnit(가장 대중적) : 개발환경(x)에 따라 Unit테스트를 도와주는 도구

- 대표적인 xUnit 프레임워크

• JUnit - Java
• DBUnit - DB
• CppUnit - C++
• NUnit - .net

이 중에서 자바용이 JUnit을 앞으로 사용

 

- 아직 많은 회사에서 JUnit5보다는 JUnit4로 테스트 코드를 작성하기 때문에 이 프로젝트에서도 JUnit4로 테스트 코드 작성