Spring Boot와 AWS로 혼자 구현하는 웹 서비스 - 2장 Spring Boot에서 테스트 코드를 작성하자

2장의 목표 : 테스트 코드 작성의 기본을 배운다.

 

TDD와 단위 테스트

TDD와 단위 테스트는 서로 다른 이야기

 

TDD : 테스트가 주도하는 개발하는 것으로 테스트 코드를 먼저 작성하는 것부터 시작

 

레드 그린 사이클

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

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

 - 테스트가 통과하면 프로덕션 코드를 리팩토링(Refactor)

 

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

테스트 코드를 꼭 먼저 작성하는 것도 아니고, 리팩토링도 포함되지 않고 순수하게 테스트 코드만 작성하는 것을 말한다.

 

단위 테스트 장점

 - 개발단계 초기에 문제를 발견하게 도와준다.

 - 개발자가 나중에 코드를 리팩토링하거나 라이브러리 업그레이드 등에서 기존 기능이 올바르게 작동하는지를 확인할 수 있다.

 - 기능에 대한 불확실성을 감소시킬 수 있다.

 - 시스템에 대한 실제 문서를 제공하여 문서로도 사용 가능

 

빠른 피드백

단위 테스트를 배우기 전에 진행한 개발 방식

1. 코드를 작성

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

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

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

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

 

여기서 2 ~ 5는 매번 코드를 수정할 때마다 반복해야만 하며 톰캣을 재시작하는 시간은 수십 초에서 1분 이상이 소요되기도 하며 수십 번씩 수정해야 하는 상황에서 아무런 코드 작업 없이 1시간 이상 소요되기도 한다.

 

왜 계속 톰캣을 내렸다가 다시 실행하는 일이 반복되는지?

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

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

 

두번째

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

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

 

세번째

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

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

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

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

 

기술이자 습관이 되어야한다.

 

HelloController 테스트 코드 작성하기

Spring Boot에서 Application 클래스는 앞으로 만들 프로젝트의 메인 클래스

@SpringBootApplication으로 인해 스프링 부트의 자동 설정, 스프링 Bean 읽기와 생성을 모두 자동으로 설정

@SpringBootApplication이 있는 위치부터 설정을 읽어가기 때문에 이클래스는 항상 프로젝트 최상단에 위치해야만 한다.

 

main 메소드에서 실행하는 SpringApplication.run으로 인해 내장 WAS를 실행

 

내장 WAS란?

별도로 외부에 WAS를 두지 않고 애플리케이션을 실행할 때 내부에서 WAS를 실행하는 것

이렇게 되면 항상 서버에 톰캣을 설치할 필요가 없게 되므로 '언제 어디서나 같은 환경에서 스프링 부트를 배포'할 수 있다.