테스트 코드 작성 규칙

[02ggang9]

Test Fixture 사용하는가

긴 토의를 거친 주제이므로 별도의 Discussion으로 분리했습니다. 아래의 링크에서 확인하실 수 있습니다.

Test Fixture를 사용하는가

테스트 메서드 이름과 @DisplayName

1. 영어 메서드를 사용하고 뒤에 성공인지 실패인지 작성하자 (Ex. saveImages_success())
2. 한글 메서드를 사용하자 (Ex. 상벌점_타입_생성을_성공해야_한다())

위의 두 가지 논의가 있었습니다.

첫 번째 방법은 영어 메서드라 읽고 쓸 때 가독성이 떨어지고 시간이 걸린다는 단점이 있었지만, 성공인지 실패인지 한 눈에 알 수 있었습니다.
두 번째 방법은 한글로 메서드를 작성하기 때문에 가독성이 높지만 메서드 중간에 성공, 실패가 있어 한 눈에 알 수 없었습니다.

논의 끝에 두 가지 방법의 장점만 취해 한글 메서드로 작성을 하고 뒤에 성공인지 실패인지 작성하도록 결정했습니다.

@Test
@DisplayName("정상적으로 모집글을 삭제한다.")
void 정상적으로_모집글을_삭제한다_성공() {}
void 정상적으로_모집글을_삭제한다_실패() {}

@Nested 사용

Nested 사용은 자율로 하도록 결정했습니다.

HTTP 수동 테스트 vs API 테스트

HTTP 수동 테스트

• 장점: 작성이 매우 쉽고 간단합니다.
• 단점: 순서가 보장이 안됩니다. 테이터 롤백을 수동으로 해야 합니다. Application을 실행해야 합니다.

API 테스트

• 장점: 유효성, 권한 검사를 할 수 있습니다. 커스텀 어노테이션을 테스트할 수 있습니다. Application을 실행하지 않아도 됩니다.
• 단점: 학습 비용이 듭니다. 코드 작성에 시간이 오래 걸립니다.

최종 선택은 API 테스트가 되었습니다. 이유는 API 테스트의 장점이 너무 많았고 백엔드 인원 대부분이 API 테스트를 할 수 있기 때문에 학습 비용이 적을거라 생각했습니다.

단위 테스트, 통합 테스트

통합 테스트

• 문서화 테스트
• API 테스트

단위 테스트

• 도메인 테스트
• 서비스 테스트
• 레포지토리 테스트 (직접 작성한 쿼리만 테스트)

TDD

TDD는 각자의 스타일이기 때문에 자유로 결정했습니다.