bmh8993 / study-tdd Goto Github PK

6장

테스트 코드의 구성 요소

• 상황, 실행, 결과 = given, when, then
• 어떤 상황이 주어지고, 그 상황에서 기능을 실행하고, 실행환 결과를 확인한다
• 테스트 코드 작성에 도움이 되는 구조일뿐 모두 이 구조로 만들 필요는 없다.

외부 상태의 영향

• 외부 상태에 따라 테스트이 성공 여부가 바뀌지 않으려면 실행 전에 외부를 원하느 ㄴ상태로 만들거나 테스트 실행 후에 외부 상태를 원래대로 되돌려 놓아야 한다.
• 외부 요인은 테스트 코드에서 다루기 힘들다.
• 대역(실제 구현을 대신하는 구현)을 사용하자. 이 대역을 통해서 외부 상황이나 결과를 대체할 수 있다.

7장

• 파일 시스템, DB, HTTP 통신 -> 테스트를 작성하고 실행하는데 어려움
• 대역 즉 test double을 사용해서 테스트를 진행하자.
• cardNumberValidator는 실제 서버와 통신하는 클래스이지만 stubCardNumberValidator을 대역으로 사용.
• autoDebigInfoRepository -> memoryAutoDebigInfoRepository
• Mock 객체를 통한 스텁과 스파이를 대체
• 의존 도출과 대역 구성
  • 제어하기 힘든 상황을 별도 타입으로 분리
  • 테스트 코드는 별도로 분리한 타입의 대역을 생성
  • 생성한 대역을 테스트 대상의 생성자 등을 이용해서 전달
  • 대역을 이요해서 상황 구성
• mock 객체의 남발은 좋지 않음
  • 대역 클래스를 만들지 않아서 편할수도 있지만, 남발하게 되면 겨로가 검증 코드가 길어지고 복잡해 보일수도 있다.
  • DAO나 repository 같은 저장소에 대한 대역은 mock보다 메모리를 이용한 가짜 구현이 관리에 유리하다

8장

• 테스트가 어려운 상황과 해결
  • 하드 코딩된 경로
    • sol) 세터 사용
  • 의존 객체를 직접 생성
    • sol) 의존 대상 주입 받기
  • 정적 메서드 사용
    • 정적 메서드가 외부 라이브러리를 사용하고 있다면 감싸서 클래스 구현 (AuthService)
  • 실행 시점에 따라 달라지는 결과 (date, random…)
    • sol) 시간이나 임의 값을 생성하는 기능을 분리
  • 역할이 섞여 있는 코드

TDD

큰 흐름

• 테스트 코드 작성 > 테스트를 통과시키 위한 개발. 딱 통과를 위해서만
• 테스트 > 코딩 > 리팩토링

어떻게 작성할 것인가?

• 쉬운 경우에서 어려운 경우로 진행
• 예외적인 경우에서 일반화, 추상화하는 경우로 진행

주의사항

• 예외 상황을 먼저 테스트 해야한다.
• 초반에 예외 상황을 테스트하면, 버그 발생, 코드 복잡성을 높이는 상황들이 줄어든다.

완급조절

• 인풋, 아웃풋
• 상수를 사용해서 테스트를 통과시키고 일반화하는 과정을 연습하는 시간이 필요하다.

TDD 과정 상세

• 쉬운 것부터 테스트
• 예를 추가하면서 구현을 일반화 한다.
• 예외 상황을 처리한다.
• 중간에 코드 중복을 확인하고 리팩토링한다.
• 마지막에 코드를 한번 더 정리한다.

TDD를 위한 준비

• 기능 명세가 중요하다. 기능 명세를 구체화해야한 ex. 회원가입이면 ID validation, DB 저장하는 경우

TDD를 통해서 얻는 이점

• 통과할 만큼만 작성한다.