TDD (1) - TDD의 정의와 중요성

TDD가 왜 중요할까?

토비의 스프링 3.1에서 나온 것이랑 똑같은 개념

현재는 코드가 정확히 동작하더라도, 코드가 유지보수되며 확장될 때 코드가 수정되더라도 소프트웨어가 정상적으로 동작하는지 확인할 수 있다.

개발해야하는 스코프가 더 많아지고 소프트웨어의 규모가 커짐에 따라 예측하기 힘든 행동 패턴에 의한 장애가 발생

요구사항이 변경되었을 때 기존의 기능에 영향이 없는지 확인

결론 - 지속적인 품질유지와 빠른 변화 대응을 위해

TDD가 무엇인가?

1. RED : 먼저 실패하는 테스트를 작성하라 (테스트 먼저 작성하고 동작하는 코드 만들기)

2. GREEN : 최소한의 코드 구현으로 통과

3. Refactor : 코드 개선하기

TDD는 다음의 원칙을 따른다

• 항상 테스트를 먼저 작성
• 작고 명확한 테스트를 작성
• 명확한 책임 분리와 느슨한 결합
  • 유효성 검증 책임을 서비스가 아닌 도메인 객체에?? -> (Validation 어노테이션 사용을 말하는건가??)
  • 객체 간 의존성을 낮추기
• 단위 테스트 우선
  • Mock 객체를 적극 활용
• 검증 -> 실행 -> 저장 -> 반환의 명확한 흐름 준수
• 지속적 리팩토링
  • 테스트 통과 이후에도 리팩토링으로 코드 품질을 개선. 개선 이후에도 당연히 테스트해봐야함

단점은?

• 초기 개발 시간 소모 증가 ( 그러면 사이드 프로젝트에서는 이걸 쓰지 말아야 하나? )
  • 나중에 유지보수할 때 다 보상될까? 장기적으로 도움이 될 듯?
• 테스트 코드 관리 부담
• 일단 어려움 ( 초보 개발자한테는 )

테스트 더블

실제 객체를 대신하여 테스트를 위해 사용되는 대역 객체 -> Mockito?

Mock과 Stub

• Mock
  특정 함수가 호출되었는지, 정해진 행동을 수행하였는지
  객체의 행동에 초점
  특정 메서드 호출 여부 검증 ( 몇 번 호출되었는가? ) -> 굳이 테스트할필요 있나...
• Stub
  미리 준비된 응답을 제공하여 특정 상태를 유지
  객체의 상태 (State)
  미리 정해둔 데이터를 반환하여 테스트 수행 (Assertion?)

장점

외부 API나 객체에 의존하지 않아 격리된 환경에서 테스트 가능. 외부 객체에 의존하지 않는다? -> 외부 객체의 코드가 변경되어도 영향을 받지 않는다.

테스트 피라미드

아래로 갈수록 비용이 낮고, 실행 속도가 빠름 -> 상단의 단계는 최소화하기

테스트 코드의 종류

단위 테스트 (Unit Test)

단일 기능이나 함수, 클래스 단위의 작은 코드 블록 테스트
코드 작성과 동시에 작성해야함

통합 테스트

서로 다른 모듈 간의 상호작용 테스트
핵심 비즈니스 로직이 포함된 모듈 또는 서비스 간의 상호작용이 중요한 지점에서 작성

E2E 테스트

실제 사용자의 전체 애플리케이션 흐름
배포 전 시스템이 문제없이 작동하는지 검증

그러면 실무에서는?

보통 비즈니스 로직이 있는 Service 레이어에서만 테스트 진행

• 개발 레벨 통합 테스트
  • 개발 레벨에서는 여러 컴포넌트(컨트롤러, 서비스, 리포지토리)가 정상적으로 동작하는지 검증
  • 코드 단위 -> 모듈 간 상호작용을 테스트
  • JUnit + H2 + @SpringBootTest 사용
• QA 단계 통합 테스트
  • 흔히 말하는 "통합 테스트 환경"
  • 여러 개발자가 협업해서 만든 기능을 통합 환경에 배포하여 테스트
  • 기능 플로우 테스트

E2E 테스트는?
이것도 UI가 있고 없고에 따라 다름
UI가 있으면 실제 버튼을 눌러보며 기능을 테스트하는식
없다면 Postman을 사용하여 API를 테스트하는 방식

내가 지켜야 하는 테스트 작성 규칙

1. 단위 테스트
2. 외부 의존성(Mock) 처리
3. 재현 가능한 테스트 작성 -> 랜덤값 사용 X
4. 명확한 테스트 이름
5. 명확한 Assertion
6. 테스트 간 상태 공유 X
7. 비동기 처리 시에는 Sleep 사용 시에는 Awaitility 사용하기
8. 과도한 Mock 검증하지 않기 -> 행동보다는 구현 방법을 검증하라?

Mock 객체를 어떻게 써야하지? 아직 잘 못쓰는데