클린코드(Clean Code) 9장 - 단위테스트

1. 테스트 코드가 중요한 이유 : 실수를 잡아주는 역할, 실제 코드 못지 않게 중요

- 테스트케이스는 변경이 쉬워야 한다

- 테스트코드가 지저분하면 안 하느니만 못하다

- 테스트는 실사용에 적합한 설계를 유도

- 테스트는 자동화되어야 한다 : 실제로 경우의 수 나누어서 직접 테스트하기 머리 터짐.

* Given(테스트 조건) - When(테스트 동작) - Then(결과 확인) 패턴

 

2. 테스트의 종류

- Unit test : 프로그램 내부 개별 컴포넌트 동작 테스트. 배포 전 자동 실행

- Integration test : 이바닥 말로 통테. 프로그램 내부의 개별 컴포턴트를 합쳐서, 동작을 테스트. 컴포넌트 간의 인터랙션을 확인하기 위해 필요한 과정

- E2E test : end to end test. 실제 유저의 시나리오대로 네트워크를 통해 서버의 endpoint 호출하여 테스트

구글은 이를 7:2:1 정도로 가져가기를 추천하고 있음.

 

실제로 이번 프로젝트 수행하면서도 SI 개발자들이 개발해서 테스트계 올려주면 -> 인수받는 SM 이 유닛테스트 진행 -> 어느정도 완료되면 통합 테스트 수행 -> 업무팀 불러다가 실제 시나리오대로 테스트 시키기 순으로 테스트가 진행됨

 

*많이 사용되는 테스트 라이브러리

- Junit: 나도 실무에서 사용하는 단위테스트 프레임워크. 테스트케이스 입력하여 돌리면 결과 나오는 형식

-Mockito: Mock 객체를 쉽게 만들고, 관리하고, 검증할 수 있는 방법을 제공하는 프레임워크

(Mock: 진짜 객체와 비슷하게 동작하지만, 프로그래머가 직접 행동을 관리하는 객체)

-Wiremock: 테스트용 웹서버

-Pact: 소비자 주도 계약 테스트 프레임워크 / 대규모 계약 cdc 처리할때 사용하는듯

-Selenium: 테스트 자동화툴. QA인턴 하던 시절 ui-driven e2e테스트할때 도입 시도했는데 생각같이 쉽게 되진 또 않던

-REST-assured:  Java 라이브러리를 사용하여 REST 어플리케이션의 HTTP Endpoint에 초첨을 맞춘 테스트 도구

 

3. Test double : 테스트에서 원본 객체를 대신하는 객체

-stub : 원래의 구현을 최대한 단순한 것으로 대체. 테스트를 위해 프로그래밍된 항목에만 응답. 상태 검증

-spy : stub역할을 하면서 호출에 대한 정보 기록

-mock : 행위를 검증하기 위해 가짜 객체를 만들어 테스트. 행위 검증

 

4. FIRST원칙

Fast : 테스트는 빨리 돌아야 한다. 자주 돌려야 하기 때문이다.

Independent: 각 테스트를 독립적으로 작성한다. 의존성이 생기면 실패한 원인이 다른 테스트의 실패인지 코드 오류인지 뭔지 알 수가 없다.

Repetable: 테스트는 어떤 환경(실제/QA/,,,)에서도 반복 가능해야 한다.

Self-validating: 자기 검증. 모든 테스트는 bool값으로 T/F 둘 중 하나의 결과가 나와야한다.

Timely: 테스트하려는 실제 코드를 구현하기 직전에 테스트코드를 구현한다.