[단위 테스트의 기술] 5장 : 격리 프레임워크

이 글은 단위테스트의 기술을 읽고 정리한 글입니다. 개인적으로 도움이 되었던 장을 정리하여 업로드합니다.

5장에서는 javascript의 격리 프레임워크를 사용하여 목 / 스텁 객체를 생성하는 것에 대해 다루었다.

나에게는 javascript의 격리 프레임워크 사용법 혹은 목/ 스텁 객체 생성 관련된 내용은 크게 와닿지 않아, 아래 내용만 정리한다.

격리 프레임워크의 장점과 함정

장점

• 손쉬운 가짜 모듈, 가짜 객체 생성
  • 직접 가짜 인터페이스, 모듈을 만들어 목 / 스텁으로 사용할 필요 없이 프레임워크가 만들어주어 boiler plate 코드를 줄여준다.
  • 다만, 이는 서드 파티 구현에 강하게 결합될 수 있다.
    • 어차피 직접 가짜 인터페이스를 구현하든, 모의 프레임워크를 사용하든 서드 파티 구현에 강한 결합이 생기는 것은 어쩔 수 없지 않나? 라는 생각이 든다.

주의해야 할 점

1. 대부분의 경우 모의 객체가 필요하지 않다.

• 작업 단위에는
  • 반환 값
  • 상태 변화
  • 서드 파티 의존성 호출
  • 이렇게 세가지 종료점이 존재한다.
• 서드 파티 의존성 호출만 모의 객체를 사용했을 때 이점을 누릴 수 있으며, 나머지는 충분히 반환 값 검증, 상태 변화에 대한 검증으로도 테스트가 가능하다. → 따라서 대부분의 경우 모의 객체(==목. 스텁은 지금 말하는 모의 객체에는 해당하지 않는다고 생각한다.)가 필요하지 않다.

2. 읽기 어려운 테스트 코드

• 하나의 테스트에 많은 목을 만들거나, 검증 단계를 너무 많이 추가한다면
  • 테스트 가독성이 떨어져 유지보수가 어렵고
  • 무엇을 테스트하는지 이해하기 어렵다
• 따라서, 하나의 테스트는 최대한 하나의 목만을 만들며, 여러개의 목이 필요하다면 최우선적으로 테스트를 쪼개는 것을 고려해 보자.

3. 잘못된 대상 검증

• 실제로 의미 있는 동작을 검증해야 한다. 아래와 같이 의미 없는 동작을 검증하는 행위를 피하자.
  • 내부 함수가 다른 내부 함수를 호출했는지 검증(다른 내부 함수가 종료점이 아닌 경우.)
  • 스텁이 호출되었는지 검증(스텁은 단순히 반환 값을 뱉어주는 객체이므로, 호출에 대한 검증은 진행하지 않는다.)