TOC
참고
본 내용은 단위 테스트의 기술을 읽고 정리한 내용입니다.
책의 내용과 함께 개인적인 의견과 생각, 학습을 담아 작성하였습니다.
상호 작용 테스트, 목, 스텁
상호 작용 테스트
- 작업 단위가 제어할 수 없는 영역에 있는 의존성과 어떻게 상호 작용하고 메 시지를 보내는지(함수를 호출하는지) 확인하는 방법
- 모의 함수(mock functions)나 모의 객체 (mock objects)를 사용
목(mock)
- 외부로 나가는 의존성에 중점
- 단위 테스트에서의 종료점
- 호출되었는지 검증하는 것이 중요
- 1 테스트, 1 목
- 목이 여러 개라는 것은 하나의 테스트에서 여러 요구사항을 테스트한다는 의미
스텁(stub)
- 내부로 들어오는 의존성에 중점
- 검증할 필요가 없다.
- 1 테스트, N 스텁 가능
- 최종 결과를 달성하는 과정에서의 상호작용
목과 스텁의 구분
- 목과 스텁의 차이를 분명히 하지 않으면?
- 복잡한 테스트에서 가독성과 유지보수성이 떨어지는 테스트를 만들 수 있다.
- 테스트마다 목을 여러 개 만들 수 있다.
- 스텁을 검증하게 된다.
- 목: 작업 단위의 요구사항
- 스텁: 들어오는 정보나 동작
저의 의견
이전 장에서 등장한 스텁과 목은 개념이 어려운 탓인지 스터디 팀원들 사이에서도 해석이 다양했고, 혼란을 많이 겪었던 개념입니다. 다시 한 번 짚어줘서 감사하지만, 여전히 어려운 것은 사실이네요..
저는 목은 작업 단위가 시작하게 된 목적과 배경(즉, 존재에 대한 올바른 return이나 예상되는 동작)을 테스트하는 것이라고 이해했습니다. 그리고 스텁은 작업 단위가 최종 결과를 달성하는 과정에서의 내외부 의존성이나 데이터, 동작 등을 의미한다고 이해했습니다.
목에 작업 단위를 주입하는 방식
표준 방식
매개변수를 추가하여 주입한다.
함수형 방식
부분 적용(정상 중 일부만 테스트 모듈을 적용) 또는 팩토리 함수를 사용하여 주입한다.
모듈 방식
모듈 의존성을 추상화하여 주입한다.
객체 지향 방식
JS와 같은 약타입 언어를 사용하거나(duck typing), 타입이 지정된 인터페이스를 사용하여 주입한다.
인터페이스 분리 원칙
인터페이스 분리 원칙(ISP)
인터페이스에 필요한 것보다 더 많은 기능이 포함되어 있으면 필요한 기능만 포함된 더 작은 어댑터 인터페이스를 만들어야 한다는 것
- 가능한 한 함수를 작게 만들라.
- 이름을 더 명확하게 지어라.
- 매개변수를 덜 사용하라.
총평
이번 장은 이전 장에서 다뤘던 스텁처럼, 어떻게 테스트 대상 내부에서 목을 활용하는지 그 방법을 나열하는 방식이었어요. 다만 스텁과 비교하면 매개변수, 함수, 객체, 생성자 등 여러 방법론들을 쏟아냈던 것과 비슷하나, 한 번 비슷한 경험을 하고 나니 이해가 쉬웠습니다. 내용 자체에 대한 재정리는 생략했습니다.
다만 중간의 커링 함수 부분은 고차 함수로 처리하는 게 더 직관적이라는 생각이 들었고, 저자는 모듈 주입 방식을 사랑하는 것을 코드와 내용 기술만으로 느낄 수 있었습니다. 제가 '이렇게까지 해야 하나'라는 의문을 가진 코드 구성이었는데 말이죠.
다만 목과 스텁을 저희가 아직도 헷갈려 할 지 이미 알고 있었는지 다시 한 번 개념 정리, 차이점 설명 등이 이어져서 이전의 의문을 조금이나마 해소할 수 있었습니다.
