워밍업 클럽 3기 BE - 발자국 3주 차

1. 들어가며

테스트 코드 강의는 미리 봤었고, 그 때 굉장히 오래 걸렸던 것 같네요. 아마 커리큘럼대로 따라가려면 굉장히 힘들었을 것 같아요...

이번 주차 내용은 저한테는 굉장히 도움이 많이 됐었던 내용이였습니다.
실제로 참고해서 회사 프로젝트에 테스트 코드를 적용하기도 했었구요.

테스트 코드에 대한 막연한 두려움을 없애준 강의라서 정말 듣기 잘했다고 생각한 강의였습니다.

2. 학습했던 내용 나만의 키워드로 작성하기

섹션 6. Spring & JPA 기반 테스트

Layered Architecture
- 관심사의 분리 때문에 레이어를 분리
단위 테스트 VS. 통합 테스트
- 여러 객체가 협력해서 어떤 하나의 기능을 동작한다면 통합테스트가 필요함
- 단위 테스트만으로 커버하기 어려운 영역들이 생기기 때문
IoC, DI, AOP
ORM, 패러다임의 불일치, Hibernate
Spring Data JPA
@SpringBootTest VS. @DataJpaTest VS. @WebMvcTest
- @SpringBootTest
  - 스프링에서 통합 테스트를 위해 제공하는 에노테이션
  - @SpringBootTest 에는 트랜잭션이 달려있지 않음 -> 더 선호
- @DataJpaTest
  - jpa 관련된 빈들만 주입해서 서버를 띄워주기 때문
- @WebMvcTest
  - 컨트롤러 레이어만 딱 떼서 테스트를 하기 위해 컨트롤러 관련 빈들만 올릴 수 있는 가벼운 테스트 어노테이션
  - @Controller와 @ControllerAdvice 등과 같은 빈만 주입 됨
@Transactional (readOnly = true)
- 읽기 전용으로 하면 CRUD 작업 중에 CUD 작업이 동작하지 않음
CQRS
- Command 와 Query 를 분리해서 서로 연관이 없게끔 하려는 것
@RestControllerAdvice, @ExceptionHandler
- 커스텀 예외를 사용해서 처리하는 것도 자주 쓰이는 방법
Spring bean validation
- @NotNull, @NotEmpty, @NotBlank, ...
- 컨트롤러에서는 최소한의 검증만 하고 도메인 레이어나 서비스 레이어에서 검증할 것들은 따로 처리해서 책임을 잘 분리하기
MockMvc
- MockMvc 란 Mock(가짜) 객체를 사용해 스프링 MVC 동작을 재현할 수 있는 테스트 프레임워크
ObjectMapper
@MockBean
- 스프링 컨테이너에 mockito 로 만든 Mock 객체를 넣어주는 역할
- 예시로, ProductService 빈에다가 적용을 하면 ProductService Mock 객체를 대신 스프링 컨테이너에 넣어줌

3. 학습 회고

너무나 바쁜 한 주를 보냈습니다. 정신이 없었네요.

옛날에 정리한 내용과 인강을 2배속으로 다시 봤습니다. 분명 정리를 했는데 처음 듣는 것 같은 내용들이 있어서 당황하긴 했습니다 ㅎㅎ.. 역시 완전히 자신의 것으로 만드려면 수많은 반복이 필요한 것 같네요.

이번 기회에 반복할 수 있어서 좋은 기회였다고 생각합니다.
특히 반복하면서 옛날에 들을 때는 인지하지 못했던 실무적인 관점이 다시 보이더라구요? 굉장히 의미 있었던 것 같습니다.

4. 미션 회고

미션 Day 11

사실 이번 미션은 회고하기가 애매합니다.
냉정하게 저 스스로에 대한 평가를 하자면 열심히 했다고 보기가 어렵기 때문이죠.
스프링 기반이 아니라서 단순히 미션의 기준에 맞춰서 필요하다고 생각한 것만 처리했습니다. (사실 코틀린 스터디를 따로 시작했는데 여기에 에너지를 너무 쏟아서,,,)

다음주 라이브 시간에 딴 분들의 코드 리뷰를 보면 깨달음과 반성을 동시에 할 것만 같네요.. 😅😅😅