이규원님의 현실 세상의 TDD 깊은 곳, 5편 : Mockists vs Classicists

테스트 주도 개발의 깊은 곳 5편, Mockists vs Classicists 다.

테스트 대역에 사용함에 있어 주의해야할 점이 주된 내용이며, 실습 위주 교육이다 

여기에 실습 관련 코드는 포함하지 않으니 

📖 자세한 내용이 궁금하면 이규원 님의 TDD 수강하는 걸 추천드립니다. 👍 

The RED : 이규원의 현실 세상의 TDD : 안정감을 주는 코드 작성 방법 | 패스트캠퍼스

---

Sociable 테스트

단위테스트가 SUT를 구동할 때 의존해야할 의존대상까지 구동하여 테스트

 

Solitary 테스트

위와 비슷하지만 의존대상이 아닌 테스트 대역으로 테스트 

 

 

가정의 안정도

테스트 대역 사용으로 얼마나 신뢰할 수 있는가? (의존성 인터페이스의 복잡도를 수학공식으로 보여주시는데 공식은 이해못함.)

- 인터페이스가 단순할 수록 1에 가까워 짐 (안정)

- 인터페이스가 복잡할 수록 0에 가까워 짐 (불안정)

 

 

Mock의 위험

상태 검증 vs 행위 검증

: Mock을 사용하면 행위 검증에 가깝다. 테스트를 정상적으로 돌리기 위해 행위 중심으로 대역을 만들기 때문

 

정보 숨김 위배

: 테스트 대역을 만들기 위해선 내부 구현 행위를 알아야한다

 

테스트가 SUT 구현에 의존, 고통스럽고 불안한 리팩터링

: 리팩터링으로 내부 구현이 변경되면 테스트 대역도 같이 변경해야 하니 고통이 따라온다, 사용하는 곳이 많아질 수록 실수할 확률이 올라간다. 

 

---

후기

이전 시간에는 테스트 대역에 대한 장점이였다면 이번에는 대역의 위험성이였다.

테스트 대역 사용으로 테스트를 어느 정도 신뢰있게 검증이 가능할 수 있지만,

실습을 통해 테스트가 행위 위주 검증으로 변경되어 위험이 있다는 걸 알게 되었다.

 

그리고 Mockists, Classicists 같이 테스트 기법, 유형, 패턴, 스타일에 따라 결과물이 달라진걸 볼 수 있었다.
 

다음 시간에는 테스트를 하다보면 겪게되는 private 메소드를 테스트를 해야한지에 대해 알아본다.