상태 검증과 행위 검증

June·2022년 2월 14일
1

우테코

목록 보기
3/84
post-custom-banner

코드를 어떻게 작성하는게 좋을까요?
코드에서 Racing이 컨트롤러 역할을 하고 있는데, 이런 컨트롤러 역할을 하는 메서드들은 테스트 찾아 봤을 때는 '어떤 메서드가 실행되었는지 여부'를 확인해주는 라이브러리가 있는데 이것을 이용해서 다른 메서드를 정상적으로 호출했는지만 테스트 해주면 되는 것일까요?

결론부터 말하자면 컨트롤러에서 테스트하고 싶은 부분이 있으면 해당 부분을 도메인 레벨로 내려서 테스트해보는 걸 도전해보시는 걸 권장합니다. 나중에 외부 라이브러리에 의존하게 되고, 테스트하기 불가능하거나 어려운 부분이 있다면 행위 검증이라도 해야겠지만 레벨1 미션을 하는동안에는 아마도 필요가 없을 거 같네요.

  • SUT(System Under Test) : 주요 객체(primary object)
  • 협력객체(collaborator) : 부차적 객체(secondary objects)
  • 테스트 더블(Test Double) : 테스팅을 목적으로 진짜 객체대신 사용되는 모든 종류의 위장 객체 (Dummy, Fake Object, Stub, Mock)

상태 검증

상태검증은 메서드가 수행된 후 SUT나 협력객체의 상태를 살펴봄으로써 올바로 동작했는지를 판단하게 된다

SomeClass someClass = new SomeClass();
someClass.someMethod();

assertThat(someMethod.someStatus()).isEqualTo(true);

someStatus값이 true인지 상태 검사

  • 행위검증은 상태검증과는 다르게 SUT가 협력객체의 특정 메서드가 호출되었지 등의 행위를 검사함으로써 올바로 동작했는지 판단하게 된다
SomeClass someClass = new SomeClass();

verify(someClass).someMethod();

someClass의 someMethod가 실행되었는지 행위 검사

stub vs mock

stub

  • 호출이되면 미리 준비된 답변으로 응답하는 것
  • 테스트시에 프로그램된 것 외에는 응답하지 않는다
  • 협력객체의 특정 부분이 테스트하기 힘들 경우 stub을 사용하면 수월하게 테스트할 수 있다
  • 일반적으로 우리가 mock으로 잘못 알고있다

mock

  • 다른 테스트더블과는 다르게 행위검증 사용을 추구한다

상태검증 vs 행위 검증 선택

행위검증의 경우 특정 메서드의 호출과 같은 것을 검증하기 때문에, 구현에 굉장히 의존적이게 된다. 이 말인 즉 프로덕션 코드가 변경되면 테스트코드가 변경될 확률이 높아진다는 것을 의미한다

상태검증의 경우 상태를 검증하기 위해 상태를 노출하는 메서드가 많이 추가될 수 있다
이러한 이유로 대체적이면 상태검증을 사용하는것이 좋다

https://joont92.github.io/tdd/%EC%83%81%ED%83%9C%EA%B2%80%EC%A6%9D%EA%B3%BC-%ED%96%89%EC%9C%84%EA%B2%80%EC%A6%9D-stub%EA%B3%BC-mock-%EC%B0%A8%EC%9D%B4/

post-custom-banner

0개의 댓글