테스트 코드 자체 유지보수성 좋아야 함 → 지속적으로 테스트 작성 ⇒ 소프트웨어 품질 ↑

주의사항

• 변수나 필드를 사용해서 기댓값 표현하지 않기
  • (+) 코드 가독성 ↑ / 객체 생성 시 사용한 값 알아보기 위해 필드와 변수 참조 X
• 두 개 이상을 검증하지 않기 = 한 가지만 검증
  • (+) 테스트 집중도 ↑
• 정확하게 일치하는 값으로 모의 객체 설정하지 않기 = 가능한 범용적인 값 사용
  • (+) 함께 코드 수정해야 하는 빈도 ↓
• 과도하게 구현 검증하지 않기 = 내부 구현보다 실행 결과 검증
• 셋업을 이용해서 중복된 상황을 설정하지 않기 → @BeforeEach로 코드 중복 제거 But, 영향 받는 테스트 메서드 X ⇒ 상황 설정 코드는 테스트 메서드 안에 위치
  • 통합 테스트에서 데이터 공유 주의하기
    • 모든 테스트가 같은 값 사용하는 데이터 ex. 코드값 데이터
      • 거의 변경 X ⇒ 공유 O
    • 테스트 메서드에서만 필요한 데이터 ex. 중복 ID 검사 위한 회원 데이터
      • 특정 테스트에서만 생성 → 테스트 코드가 완전한 하나가 되도록
  • 통합 테스트의 상황 설정을 위한 보조 클래스 사용하기
    • (+) 어떤 상황 구성하는지 이해 O, 각 상황 구성하기 위한 코드 중복 X ⇒ 유지보수성 ↑
• 실행 환경이 다르다고 실패하지 않기
  • ex. EnabledOnOS({ OS.LINUX, OS.MAC }), DisabledOnOS(OS.WINDOWS)
• 실행 시점이 다르다고 실패하지 않기
• 랜덤하게 실패하지 않기 = 직접 랜덤 값 생성 X 생성자 ~> 값 받기
• 필요하지 않은 값은 설정하지 않기 = 필요한 값만 설정
  • 단위 테스트를 위한 객체 생성 보조 클래스
    • 빌더 패턴 → 코드 간결 + 유연성 ↑
• 조건부로 검증하지 않기
  • 테스트 → 성공 or 실패 ⇒ 반드시 단언 실행해야 함 → 조건에 대한 단언도 추가
• 통합 테스트는 필요하지 않은 범위까지 연동하지 않기
  • @JdbcTest: DataSource, JdbcTemplate 등 DB 연동과 관련된 설정만 초기화 ⇒ 다른 빈 생성 X → 스프링 초기화 시간 ↓ (↔ @SpringBootTest)
• 더 이상 쓸모 없는 테스트 코드 → 유지보수 도움 X ⇒ 삭제