[워밍업 클럽 2기 - Clean Code & Test Code] 4주차 발자국

워밍업 클럽 2기: Clean Code & Test Code의 4주차 발자국 작성입니다.
3주차 발자국 보러가기

📝 학습 내용

Q. Presentation Layer의 특징은?

클라이언트로 부터 입력을 받아서 비즈니스 계층으로 해당 요청을 보내는 계층
요청을 제일 먼저 받는 계층
입력 데이터에 대한 기본적인 검증을 수행한다
- Presentation 계층에서의 검증과 Business 계층에서의 검증을 분리해서 생각해야 한다
- Presentation 계층에서는 보통 형식적인 검증을 한다
  - 예시: 필수 입력 값 검사, 데이터 타입 검사, null 검사, 빈 문자열 검사
- Business 계층에서는 비즈니스 로직에 따른 도메인 유효성 검사가 이루어진다
Business 계층으로 부터 결과를 받아서 클라이언트로 반환한다
컨트롤러에서 사용하는 요청 DTO가 서비스 계층으로 침투하지 못하도록 컨트롤러 계층에서 서비스 전용 DTO로 변환하는 것을 권장한다(상황에 따라 다를 수 있을것 같다. 만약 받는 포맷이 변할 가능성이 거의 없다면, 그냥 컨트롤러의 DTO를 쭉 사용해도 괜찮지 않을까 생각이 된다.)

Q. Presentation Layer의 테스트 방법은?

Q. Test Double의 종류를 정리해보자면?

Dummy: 아루런 동작도 하지 않는 객체. 잘 사용되진 않지만, 보통 파라미터 전달용으로 사용된다.
Fake: 실체 객체와 동일한 기능은 수행하지만, 프로덕션 용도로 사용하기에는 적합하지 않은 객체.
- 예시: 인메모리로 맵을 사용해서 가짜 레포지토리를 구현하는 경우
Stubs: 테스트에서의 요청에 대해 미리 준비된 결과를 제공하는 객체. 미리 반환할 데이터가 정의되어 있고, 호출하는 경우 해당 데이터를 반환한다. 미리 정의되어 있지 않은 것들은 응답하지 않는다.
Spies: Stub이지만 정복 기록도 함께하는 객체. 호출 여부, 호출 횟수 등의 정보를 기록할 수 있다. 일부는 실제 객체 처럼 동작하고, 일부는 Stubbing할 수 있다.
Mocks: 행위에 대한 기대를 명세하고, 그 명세에 따라 동작되도록 설계 된 객체. 그러니깐 개발자가 직접 그 객체의 행동을 관리하는 객체이다.

Q. Stub과 Mock을 구분하는 기준은?

TIP. 테스트 작성을 위한 여러 팁을 정리해보면

Mockito 프레임워크를 한번 래핑하는 BDD Mockito 프레임워크를 사용해서 조금 더 자연스러운 API 네이밍으로 프레임워크를 사용할 수 있다
테스트 간의 독립성을 보장하자
- 테스트에서 전역 변수를 정의해서 사용하는 것은 권장하지 않는다
- @BeforeEach또는 @AfterEach 메서드를 사용한 레포지토리 클렌징
- @Transactional사용
Test Fixture용 클래스를 따로 분리해서 사용하는 것은 권장하지 않는다
Test Fixture를 @BeforeEach를 사용한 셋업 메서드에서 사용하는 경우, 중복 제거보다 해당 테스트에 해당 내용을 알아야하는지 고려해보고 적용하자
테스트 내용은 동일한데 입력값만 변경해보면서 테스트 해보고 싶으면 @ParameterizedTest 사용
private메서드에 대한 테스트가 필요하다면 해당 메서드의 책임을 분리할지 고민해본다
- 단순히 테스트하기 위해서 public으로 열어두는 것은 권장하지 않는다

Q. REST Docs vs Swagger의 차이는?

REST Docs
- 테스트를 통과해야 문서가 만들어지기 때문에 신뢰도가 높다
- 프로덕션 코드에 비침투적이다
- 코드의 양이 많고 설정이 상대적으로 어렵다
Swagger
- 적용이 쉽다
- 문서에서 바로 API 호출이 가능하다
- 애노테이션을 달아줘야 하기 때문에 프로덕션 코드에 침투적이다