[Practical Testing: 실용적인 테스트 가이드]
섹션 10. Outro
📌 테스트를 작성하는 마음가짐
📍 강의 정리
1. 테스트는 왜 필요할까?
1) 테스트를 아예 작성하지 않는 경우
빠르게 변화하는 소프트웨어의 품질을 일정 수준 이상으로 가져가기가 어려울 수 있다.
사람이 항상 모든 것을 테스트 해야 되는데 소프트웨어가 발전하는 속도보다 사람이 커버할 수 있는 속도와 리소스가 맞지 않기 때문에 기계에 힘을 빌려야 한다.
2) 테스트 코드를 작성하더라도 그 테스트 코드가 병목이 되는 경우
테스트 코드를 엉망으로 작성한다면 테스트 코드 자체가 애물단지가 될 수 있다. 그래서 테스트 코드를 점차 작성하기 어려워지게 되고 결국은 안짜게 되는 그런 상황이 발생할 수 있다.
혹은 테스트를 잘못 작성하면 잘못된 검증을 하게 되거나 잘못되었는데 올바르다고 인식을 하고 넘어갈 수도 있다.
2. 단위 테스트
- JUnit : 단위 테스트 도구
- 단위 테스트 : 작은 코드 단위를 독립적으로 테스트 하는 것.
- 가장 작은 레벨, 가장 작은 단위에서 풍부한 단위 테스트를 작성하는 것자체가 소프트웨어의 안정성을 보장하는 시작 단계
3. TDD
프로덕션 코드보다 테스트 코드를 먼저 우선시 작성하여 테스트가 구현 과정을 주도하도록 하는 방법론 중에 하나이다.
외부에서 프로덕션 코드를 바라보는 클라이언트 관점에서 코드에 피드백을 줄 수 있다.
4. 테스트는 문서다.
개인이 했던 고민의 결과물을 팀 차원의 지식으로 승격을 시키는 것이 중요하다.
5. Spring & JPA 기반 테스트
레이어드 아키텍처
레이어별 관심사가 다르기 때문에 레이어가 나눠지게 되었고 그에 맞추어서 테스트가 필요하다.
통합 테스트
두 가지 이상의 클래스나 혹은 듈이 결합했을 때의 시너지가 어떻게 날지 예측하기 어려울 수 있기 때문에 통합 테스트를 통해서 단위 테스트로 다 커버하지 못하는 부분을 보장 해줘야 된다.
6. Mock을 대하는 자세
- Mock : 테스트 더블, 대역
- Stubbing : 가짜 행위를 정의하는 것
- Mockito : Mock 프레임워크
- 클래시스트 vs 머키스트
7. 더 나은 테스트를 작성하기 위한 구체적 조언
- 한 문단에 한 주제 ➡ 한 테스트에 한 가지 목적의 검증만 수행
- 제어할 수 없는 값/환경에 대한 것들은 배제하고 제어할 수 있는 값들로만 테스트 대역을 만들거나 제어하기 어려운 외부 시스템같은 것들은 Mocking 처리를 한다.
- 테스트 환경의 독립성을 보장하자.
- 테스트 간 의존관계를 갖지 말자.
- Test Fixture - given절에 작성하는 테스트 대역들과 테스트 내용과 직접적인 관련이 없는 세팅은 setup절에서 구성하면 좋다.
- Test Fixture 클렌징 - deleteAllInBatch() / deleteAll() / @Transactional
- @ParameterizedTest - 다중 케이스가 필요한 경우
- @DynamicTest - 상태 공유가 필요한 시나리오 작성이 필요한 경우
- 테스트 수행하는 것도 비용이다. ➡ 공통된 환경을 모아서 환경 통합하기
- private method의 테스트는 할 필요가 없다.
- 프로덕션에 없는 메서드지만 테스트에서 필요해서 만들고 싶을 때는 고민을 해봐야한다.
8. Appendix
- 학습 테스트 : 작성하지 않은 코드 (ex 라이브러리, 프레임워크)를 재밌게 학습하기 위한 방법
- Spring REST Docs : 테스트 코드를 통한 문서 자동화 도구 중에 하나
📍 테스트 작성을 방해하는 것?
시간
비즈니스에선 시간이라는 축이 있다.
그래서 항상 한정된 시간 안에서 무언가를 만들어내야 된다.
이런 한정된 시간 내에서 올바른 테스트를 작성하려면 어떻게 해야할까?
1. 테스트 케이스를 추론하고 구체화 시키는 연습이 많이 필요하다.
2. TDD가 손에 익도록 많은 연습이 필요하다.
시간의 압박이 있는 경우에 당장 눈앞에 놓인 요구사항에 매몰되어서 프로덕션 코드를 작성하기 쉽다.
근데 잠깐 키보드에서 손을 떼고 숨을 잠시 고르고 어떤 케이스가 있어야 지금 작성하려는 프로덕션 코드가 더 단단해질까? 어떤 케이스로 검증을 하면 좋을까?를 고민을 해봐야 된다.
그리고 그 케이스들이 정리가 되었다면 빠르고 정확하게 문서로서의 테스트를 작성하고 프로덕션 코드를 그에 맞춰서 구현을 해야 된다.
📍 타협하지 않는 마음
가까이 보면 느리지만, 멀리 보면 가장 빠르다.
테스트를 작성하는 귀찮은 마음과 시간적인 압박이 있더라도 지금 시간을 30분, 1시간 더 투자해서 테스트를 작성하는 게 나중에 3시간, 10시간 또는 하루 더 수 많은 시간을 아낄 수 있다.
📑 출처
