유지보수하기 좋은 테스트 코드 작성

• 참고 내용 : "테스트 주도 개발 시작하기" (최범균 저) 10장

변수나 필드를 사용해서 기댓값 표현하지 않기

• 변수나 필드를 사용하면 값 파악이 어렵기 때문에 테스트 코드 파악이 어려워짐

두 개 이상 검증하지 않기

• 개별 검증 대상에 대한 집중도를 높이자

정확하게 일치하는 값으로 모의 객체 설정하지 않기

• 특정한 값에 대해서만 모의 객체가 리턴하도록 하면 테스트할 때 넘긴 값의 작은 변화에도 테스트가 깨져버린다.
• 정확한 값으로 호출되는 것이 중요한 테스트가 아니라면 모의 객체가 반응할 값을 너무 한정짓지 말자.
  • anyString() 등으로 해줘도 무리 없는 경우들이 많을 것이다.

과도하게 구현 검증하지 않기

• 과도하게 내부 구현을 검증하면 구현 변경으로 테스트가 깨질 가능성이 커진다.
  • 가능하면 내부 구현보다 실행 결과를 검증하자.
• 하지만 존재하는 코드에 테스트 코드를 추가하는 경우 기능 검증을 위해 구현을 검증할 수 밖에 없는 경우가 종종 생긴다.
  • 불가피한 경우에는 그렇게 하지만 나중에는 리팩토링을 통해 구현이 아닌 결과를 검증하도록 수정해나가자.

셋업을 이용해서 중복된 상황을 설정하지 않기

• 코드 파악의 어려움
  • 테스트 작성하고 시간이 많은 이후에는 셋업 메소드로 인해 코드 파악이 어려울 수 있다.
• 테스트간 불필요한 종속성
  • 서로 다른 테스트가 불필요하게 논리적으로 결합됨으로써 테스트가 깨지기 쉬워진다. (ex. 셋업 메소드 값 수정)
• 개별 메서드는 스스로 온전하게 설명이 되어야 한다.

실행 환경이 다르다고 실패하지 않기

• OS에 따라 경로 시스템이 다를 수 있음에 주의

실행 시점이 다르다고 실패하지 않기

• 실행하는 시간에 의존하는 메소드
  • 대안1) 실행 시점에 의존하는 코드는 시간 관련 객체를 인자로 받아서 실행하는 코드로 수정 -> 테스트에서 시간 관련 객체를 고정하여 검증
  • 대안2) 별도의 시간 클래스 작성
• 랜덤 값을 사용하는 메소드
  • 대안1) 랜덤 값을 생성자/인자로 받도록 수정
  • 대안2) 랜덤 값 생성을 다른 객체에 위임하고 대역 사용

테스트에 필요한 값만 설정

• 불필요한 프로퍼티까지 굳이 설정하지 말자
• null이면 안되는 프로퍼티가 많아서 코드가 복잡해진다면 테스트 코드용 팩토리 클래스를 만들어서 사용해보자.

조건부로 검증하지 않기

• 조건부로 검증하는 경우 조건문을 통과하지 않은 경우에 테스트가 실패하지 않는다.
• 조건부로 검증을 해야 한다면 조건문도 assert해서 실패할 테스트는 실패하도록 만들자.

통합 테스트는 필요하지 않은 범위까지 연동하지 않기

• @SpringBootTest 어노테이션을 사용하면 모든 스프링 빈을 초기화하므로 테스트 실행 시간이 길어질 수 있음

더 이상 쓸모 없는 테스트 코드

• ex1) 익숙하지 않은 클래스를 숙지하기 위해 작성해본 테스트 코드
• ex2) 단순히 테스트 커버리지를 높이기 위해 작성한 getter, setter 검증