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

TDD(Test Driven Develop)과 단위 테스트(Unit Test)는 다르다

 

1. TDD는 테스트가 주도하는 개발로 테스트 코드를 먼저 작성하는 것으로 시작한다.

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

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

또한 TDD와 달리 무조건 테스트 코드를 먼저 작성해야 하는 것도 아니고, 리팩토링도 포함되지 않는다.

순수하게 테스트 코드만 작성하는 것을 의미.

---

그렇다면 테스트 코드는 왜 작성해야 할까?

 

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

우리가 개발하는 실제 예시와 비교

1. 코드를 개발하고
2. 프로그램(Tomcat)을 실행한 뒤
3. Postman과 같은 API 테스트 도구로 HTTP 요청하고
4. 요청 결과를 로그나 프린트를 통해 검증한다.
5. 결과가 다르면 프로그램을 중지하고 코드 수정하고 위의 과정을 반복한다.

위와 비교해서 테스트 코드의 장점

• 테스트 코드를 작성하면 프로그램을 내렸다가 다시 실행할 필요가 없다.
• 로그나 프린트를 통해 눈으로 검증할 필요가 없고, 자동 검증이 된다.
• 개발자가 만든 기능을 안전하게 보호
  • 기존의 A 기능에 B기능을 추가
  • 기존에 잘 되던 A 기능에 문제가 생김을 발견
  • 규모가 커지면 하나의 기능을 추가할 때마다 서비스의 모든 기능을 테스트할 수 없다.
  • 기존의 A 기능을 테스트하던 코드를 통해 기존 기능이 잘 작동되는지 테스트가 가능하다.

자바의 유닛 테스트 프레임워크는 JUnit이다.

 

---

스프링 부트는 내장 WAS를 포함하고 있다.

• 내장 WAS란 외부에 별도의 Web Application Server를 두지 않고, 애플리케이션을 실행할 때 내부에서 WAS를 실행하는 것을 의미
• 이렇게 되면 항상 서버에서 톰캣을 설치할 필요가 없게 되고, 스프링 부트로 만들어진 Jar 파일로 실행하면 된다.

장점

• 언제 어디서나 같은 환경에서 스프링 부트를 배포할 수 있다.
• 외장 WAS를 사용할 경우 모든 서버는 WAS의 종류와 버전, 설정을 일치해야 한다.
• 서버가 한 대가 아니라, 여러 대인 상태에서 버전이나 설정을 바꿔줘야 한다면?
• 새로운 서버를 추가한다면? -> 매번 모든 서버의 설정을 일치시켜야 한다.

 

출처 : 스프링 부트와 AWS로 혼자 구현하는 웹 서비스

https://github.com/jojoldu/freelec-springboot2-webservice

GitHub - jojoldu/freelec-springboot2-webservice