테스트 코드에 낯선 주니어 개발자 입장에서 테스트 코드를 짜는 방법보다 어떻게 테스트 코드 작성 전략을 가져가는 것을 정하는 것이 어렵다. 테스트 작성 방법도 익숙지 않은 상태에서 올바른 테스트 코드 전략이 무엇인지 생각해야 하기 때문이다.
팀프로젝트 시작 당시에 우선 구글링에서 찾은 테스트 전략 가이드를 따라 진행 했다.
- 서비스는 @SpringBootTest , 컨트롤러는 Mock 객체 사용 (테스트 더블 사용)
- 작업을 진행 중 애매모호한 부분이 많아서 테스트와 단위 테스트와 TDD에 대해 공부가 필요해 보였다.
테스트란?
- 개발 주기에 검증단계에 있는 부분
- 소프트웨어 개발 주기는 요구사항/ 설계 → 구현 → 검증 → 배포 → 수정 → 구현 → 검증 → 배포 순으로 진행
- 검증을 잘할수록 버그 수정이 감소된다. 이는 개발 속도의 증가를 의미
- 검증 부분은 개발자의 몫이다.
- 정상상황과 예외상황 모두 검증해야 한다.
- 수동 테스트 : 코드가 아닌 직접 제품을 사용하면서 하는 테스트
→ 검증 범위 누락이 발생하고 , 모든 예외케이스를 만들기 어렵다. ⇒ 시간이 오래 걸린다. - 자동 테스트 : 코드로 하는 테스트
- 코드로 실행할 수 있는 테스트
- 회귀 테스트 (기능 수정 시 예외 상황을 발견)
- 검증 범위(커버리지)가 넓어진다.
- 자동 테스트가 시간이 많이 걸린다고 하나, 수동테스트에 비하면 테스트 시간은 매우 적은 편이다. ⇒ 수동 테스트로 찾기 어려운 예외도 수 초 ~ 수 분내로 발견할 수 있다.
단위 테스트란?
- 단위 테스트는 단위를 테스트한다는 의미이다.
- 여기 단위에 대해 보는 시각이 다르다. 하나의 기능을 보는 시각이 있고 하나의 메서드 혹은 하나의 클래스로만 보는 시각이 있다.
- 단위 테스트를 보는 시각은 크게 두 가지로 나뉘는데 고전파(Classicist)와 런던파(Mockito)이다.
- 고전파
- 켄트백 TDD에서 나타났다.
- 단위 테스트의 단위를 하나의 기능으로 본다.
- Inside → outSide 방식으로 개발한다.
기능 → 컨트롤러 - 상태 검증 -> 테스트 결과로 나오는 객체의 상태를 검증 → 안정적
- 런던파
- 테스트 더블(가짜 객체)을 사용한다.
- 단위를 하나의 클래스 혹은 , 하나의 메서드로 본다. 협력객체들을 가짜객체로 사용
- 행위 검증을 한다. -> 객체가 해당 행위를 했는지 검증
- OutSide → InSide 방식으로 개발
Controller로부터 개발 → 기능 개발 - 가짜객체를 사용하여 테스트 속도가 빠르다
- 고전파
가짜객체를 이용할 땐 새로 기능이 추가될 때마다 해당 행위가 나타났는지에 대한 코드를 추가해줘야 한다. 또한 전체적인 설계에 대한 리팩토링 기회를 얻지 못한다. (제품에 대한 디자인이 잘못되었는지 알 기회를 놓치게 된다) OutSide → Inside 방식이므로 어느 정도 설계실력이 있어야 한다.
테스트 코드와 TDD가 익숙지 않고 설계 능력이 필요한 주니어의 입장에선 그저 객체의 행위만을 검증하는 것이 아닌 개발한 기능의 전체 흐름과 설계를 테스트할 수 있는 고전파의 방법이 좋다고 생각이 들었다. 고전파라고 해서 Test Double을 아예 배제하는 건 아니다 외부 API 나 테스트하기 어려운 기능 같은 경우에 가짜객체 사용을 한다.
참고
https://www.youtube.com/watch?v=WBVjBwKx47I&list=PLwouWTPuIjUj_QqgXlFsqjUwyC0-5dZ_q
https://jojoldu.tistory.com/320
https://www.youtube.com/watch?v=n01foM9tsRo