테스트 코드의 기본 이론

테스트 코드를 작성하게 된 계기

Swagger로 테스트를 해오던 나에게 더 이상 Swagger만으로는 테스트에 한계가 있다는 것을 깨달았다.
그 이유는 이것저것 여러가지가 있었지만 요약해서 세가지이다.
첫 째, 모든 상황은 가정하고 코드를 작성했는지 별도의 문서가 필요했다. 어떤 상황에 어떤 예외가 발생해야하는지 상황에 대한 제어를 내가 최대한 꼼꼼하게 해야하지만 스웨거만으로는 그 부분을 체크하기 어려웠다.
둘 째, 어떤 메서드가 어떤 용도로 쓰이는지 별도의 문서가 필요했다. 테스트 코드를 작성함으로써 내가 의도하고 작성한 부분들을 바로바로 찾아가기가 어려웠다.
셋 째, 내 프로젝트가 유연하고 확장에 용이한 코드인지 확인하기 어려웠다. 레이어드 아키텍처의 고질적인 문제인 의존성 문제를 해결해야 테스트 코드 작업이 가능했다.

이러한 이유로 테스트코드를 작성하기 위한 공부를 시작하게 되었다!

 

테스트란?

• 직접 사용해보면서 체크리스트를 체크하는 과정 [ 인수 테스트]
• 결과값과 예상값을 다뤄보는 테스트 [ 자동 테스트]

테스트의 필요성

• Regression
  • 잘 작동하던 코드가 배포 후에는 잘 작동하지 않아 수정이 두려워지는 상황이 발생
  • 자동 테스트를 도입하기로 결정한 후 생산성이 올라갔다는 이야기가 있다.
  • 테스트를 작성하다보면 더 좋은 아키텍처를 만들 수 있다.
• SOLID
  • 테스트 코드와 솔리드 원칙을 지키면 좋은 설계와 회귀 버그 방지의 효과를 보일 수 있다.

테스트의 3분류

• API - 대형 테스트
• Integration - 통합 테스트
  • 단일 서버
  • 멀티 프로세스와 멀티 스레드를 사용할 수 있다.(h2와 같은 DB)
  • 소형 테스트보다 느리다.
• Unit - 소형 테스트
  • 매우 중요하고 빠르며 결정적인 테스트
  • Blocking Call이 없어야 한다.
  • 단일 서버 / 프로세스/ 스레드가 없어야 한다.

테스트에 필요한 개념

• SUT(Sytstem Under Test)
  • 테스트 하려는 대상
• BDD(Behavior Driven Development)
  • given-when-then 구조 추천
  • TDD에 하나 더 얹은 내용
• 상호작용 테스트
  • 메서드가 실제로 호출되는지 검증
  • 캡슐화에 위배되는 방식
  • 내부 구조를 감시하게 되어 구현에 집착하게 된다.
• 상태 기반 검증 vs 행위 기반 검증
  • 상태 기반 검증
    • 상호 작용 테스트와 유사
    • 어떤 값을 시스템에 넣었을 떄 협력 객체에 어떤 행위가 실행되었는가
• 텍스트 픽스처
  • 테스트에 필요한 자원을 생성하는 것
  • 테스트가 한 눈에 잘 안들어오는 단점이 있다.
  • 중복이 많은 경우에 생성
• 비욘세 규칙
  • 유지하고 싶은 상태나 정책이 있다면, 알아서 테스트를 만들어야 한다.

Testability

• Test Double
  • Dummy
    • 아무런 동작도 하지 ㅇ낳고, 그저 코드가 정상적으로 돌아가기 위해 전달하는 객체
  • Fake
    • 로컬에서 사용하거나 테스트에서 사용하기 위해 만들어진 가짜 객체, 자체적인 로직이 있다는 것이 특징
  • Stub
    • 외부 연동 컴포넌트에 주로 사용
    • 미리 준비된 값을 출력하는 객체
    • 보통 Mockito를 사용
  • Mock
    • 메서드 호출을 확인하기 위한 객체
  • Spy
    • 메서드 호출을 전부 기록했다가 확인하기 위한 객체

TDD란?

• Red(깨지는 테스트를 먼저 작성한다)
  • 테스트가 실패하는지까지 확인해야 한다.
• GREEN(깨지는 테스트를 성공 시킨다)
• BLUE(리팩토링한다)

TDD의 장단점

• 장점
  • 대부분의 코드를 커버하는 테스트가 생기게 된다. 신규 개발을 하더라도 부담이 없어진다.
  • 신규 개발 후 테스트에 문제가 생기더라도 어디서 발생한건지 알 수 있기 때문이다.
• 단점
  • 깨지는 테스트를 먼저 작성해야 하기 때문에, 인터페이스를 먼저 만드는 것이 강제된다. What/Who 사이클 - 어떤 행위를 누가 수행할 것인지 결정하는 과정

TDD를 바라보는 개발자의 고민

• 무의미한 테스트
• 느리고 쉽게 깨지는 테스트
• 테스트간의 병렬 처리를 제대로 다루지 못해도 발생하는 문제(잘못된 설계라는 걸 보여주는 시그널)