테스트의 구분은 대표적으로 단위 테스트/통합 테스트/인수 테스트가 존재
Unit Test 단위 테스트
- 의도된대로 개발 된 모듈 확인
- 모듈 동작에 대한 예외를 작성하여 검증
- Mock을 이용
Intergration Test 통합 테스트
- 통합 테스트는 단위 테스트가 끝난 모듈과 외부 라이브러리 또는 DB와 같이 개발자가 변경할 수 없는 모듈까지 함께 진행하는 테스트입니다. 테스트에 초점은 모듈 간 상호작용이 정상 수행여부를 체크
- Controller -> Service -> Repository -> DB
End to End 인수 테스트
- 실제로 사용자가 서비스를 사용하는 상황을 테스트하는 것으로, 인수 테스트
- 소프트웨어 내부 구조가 아닌 비지니스적 시나리오대로 잘 동작하는가 아닌가 에 있습니다. 또한, 테스트의 주체가 단위 테스트와 통합 테스트는 개발자이지만, 종단 간 테스트에서는 개발자 이외에도 QA를 포함
- 비지니스적 시나리오를 정리해서 실제로 요청을 보내고, 시나리오대로 요청에 대한 결과가 오는지 확인합니다. 웹 백엔드를 기준으로 종단 간 테스트를 진행하는 레이어는 Router — Controller — Service — Repository — DB 까지이며, 통합 테스트와 테스트가 진행되는 레이어는 같지만, 다른 점은 테스트의 목적 그리고 테스트하려는 부분이 코드 내적인 부분인지 외적인 부분(비지니스적 시나리오)를 구분
구글이 제시한 테스트 계획 비율
- 인수 테스트 10%
- Integration 20%
- Unit 70%
실제 업무에서는?
- PG웹 기준 UI와 자바 코드는 컨텍스트가 이어지는 상태
- junit을 통한 단위(도메인 모델) 테스트 보다는 사용자 중심으로 비즈니스 시나리오 중심(인수) 테스트 계획 중심
- 비즈니스 시나리오가 중심인 이상 모든 테스트는 비용이 큼
- 그럼에도 어떻게 개선해볼 수 있을까?
- 비즈니스 시나리오에서 테스트 하기 쉬운 코드와 어려운 코드를 분리 한다.
보통 테스트 하기 쉬운 코드가 도메인 모델이 됨 (단위테스트)
테스트 하기 어려운 코드는 서비스 모델 (수동/인수 테스트)
테스트 하기 쉬운 코드와 어려운 코드는 Boundary Layer에서 만나게 한다.
Boundary Layer 테스트 방법을 익힌다.
테스트 종료
- TC 수행 완료
- 인수 테스트가 성공이 되면 해당 이슈는 완료
- issue에 대한 이해당사들의 합의
어디까지 테스트해야할까? 테스트 코드는 어디까지 작성해야할까?
한 페이지에 대한 테스트를 통째로 작성한다고 했을 때 우리가 생각해볼 수 있는 테스트는 E2E 테스트다. 페이지에서 특정 버튼을 누르거나 사용자가 어떤 액션을 취했을 때 그에 맞는 처리가 일어나는지를 하나의 시나리오로 지정하고 시나리오별로 테스트를 작성해 사용자 행동을 그대로 흉내내면 손쉽게 테스트 코드를 작성할 수 있을 것으로 보인다.
-> 버튼을 누르면 서버에 데이터를 요청해 데이터를 받아오는데, 이 기능에 대한 테스트는 필요 없을까?
->버튼을 누름과 동시에 fetchUser 를 실행해 데이터를 받아올테니 E2E 테스트에서도 버튼이 제대로 동작함을 충분히 테스트한 것이 아니냐는 의문이 들 수 있다. 아예 틀린 말은 아니라고 생각한다. 하지만 확장성이 조금은 부족한 생각일 수 있다.
- 비즈니스에 따라 다름
- 100% 테스트는 존재할 수 없음
- 최소 노력으로 최대 효율
- 페이지 접속 시 배너 이미지가 제대로 불러와지는지를 배너 로드 모듈에 대한 단위 테스트 해야할까? -> 아님
굳이 해야한다면 시나리오만으로 충분 - 이런 걸 구분할 수 있어야 좋은 테스트 코드를 작성가능
- 조회 버튼을 누르면 회원 정보를 가져오는 컨트롤러 -> 명확한 수행 조건과 기준
이런 경우 단위 테스트를 적용하면 좋음
-> 그 안에서 조건을 수행한다면? 다른 코드와 연계된다면?
-> 단위 테스트만으로 불가능
-> 결국 given-when-then의 구조를 수행할 수 있는가? 테스트가 필요한가에 대한 선택과 집중이 선행되야함 정답은 없음
ATM