테스트 대역은 매력적인 도구이다 특히 단위 테스팅이나 테스트 주도 개발을 처음 배우는 프로그래머들에겐 더욱 그렇다. 하지만 모든 도구는 장점과 단점이 있고 유용한 환경이 있다. 테스트 대역을 보다 조심스럽고 효과적으로 다루는 방법을 강의를 통해 알아봤다.
Sociable 테스트 vs Solitary 테스트
Socialble 테스트
- 단위테스트가 SUT를 테스트 할 때,그 시스템이 의존하고 있는 다른 코드들도 같이 사용해서 시스템을 구동해 테스트를 하는 기법이다.
Solitary 테스트
- 의존성을 가지는 시스템을 테스트할 때, 시스템과 의존성을 분리시켜서 테스트하는 기법이다.
- 의존성을 테스트 대역을 사용해서 해결한다.
- 하는 이유 : 단위 테스트가 테스트하고자 하는 코드 덩어리 외의 나머지 코드는 테스트를 완벽하게 제어하겠다는 의도로 테스트
가정의 안정도
테스트 대역 사용으로 인해 생기는 가정의 얼마를 믿을 수 있을까?
- 테스트 대역이 구현하는 인터페이스가 단순할 수록 1에 가까워 진다. (안정)
- 테스트 대역이 구현하는 인터페이스가 복잡할 수록 0에 가까워 진다. (불안정)
Mock의 위험
- 상태 검증 vs 행위 검증 (출력을 어떻게 만들어 내는지)
- Mock을 사용했을 땐 상태 검증보단 행위 검증에 가까워진다.
- 정보 숨김 위배할 가능성이 있다.
- 테스트 대역을 만들기 위해선 내부 구현 행위를 알아야한다
- 테스트가 SUT 구현에 의존한다 -> 고통스럽고 불안한 리팩터링으로 주저하게 된다.
- 리팩터링으로 내부 구현이 변경되면 테스트 대역도 같이 변경해야 하니 고통이 따라온다, 사용하는 곳이 많아질 수록 실수할 확률이 올라간다.
회고
실습을 통해 Mockists, Classicists 같이 테스트 기법, 유형, 패턴, 스타일에 따라 결과물이 달라진걸 볼 수 있었고, 테스트가 행위 검증으로 변경되어 위험이 있다는 걸 알게 됐다.
근데 그렇게 이해가 다 되지는 않았다. 졸려서 그런 것 같다
백엔드 개발자