Day 16

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

Presentation Layer 테스트 (2)

모킹: 가짜 객체로 대신하여 정상 동작할거야 라는 것을 가정하고

프레젠테이션 레이어

즉, 테스트하고자 하는 레이어에만 집중해서 테스트하겠다

모킹이 들어가는순간 단위테스트인것인가?

Day 17

섹션7. Mock을 마주하는 자세

Mock 객체는 Mock의 역할, Stub의 역할을 동시에 할 수 있다고 한다.

나도 Classicist 쪽에 가까운 것 같다.

모킹이 100% 재현할 것이라는 것에 항상 의심을 하기 때문이다.

Day 18

섹션8. 더 나은 테스트를 작성하기 위한 구체적 조언

한 문단에 한 주제다, 하나의 테스트는 하나의 주제만을 가져야 된다

테스트 환경의 독립성을 보장하고, 테스트 간 독립성을 보장하자

테스트 수행도 비용이다. 테스트 마다 Spring Boot가 뜨는것을 줄이기 위해 환경을 통합하자.

Day 19

드디어 강의를 다 들었다.

Spring REST Docs, Swagger 둘 다 일장일단이 있는 것 같아서 팀의 내부사정에 맞게 사용하면 될 듯 싶다.

정말 의미있는 시간이었다.

Day 20

중간 점검

미션

Day 16

Layered Architecture 구조의 레이어별 테스트 작성법을 알아보았습니다. 레이어별로 1) 어떤 특징이 있고, 2) 어떻게 테스트를 하면 좋을지, 자기만의 언어로 다시 한번 정리해 볼까요?

Persistence Layer

특징: 데이터를 직접 접근하는 계층

어떻게 테스트를 하면 좋을지: CRUD에만 집중하여 테스트하자. 비즈니스 로직이 들어가면 안된다.

단위테스트같은 통합테스트로 진행하자. 수행 후 데이터를 잘 지워주자.

Business Layer

특징: 비즈니스 로직이 전개되는 계층

어떻게 테스트를 하면 좋을지: 비즈니스 로직이 정상적으로 수행되는지 통합테스트로 진행하자. 수행 후 데이터를 잘 지워주자. 예외 케이스에 더 집중해야한다. 그것이 개발자의 역량이다.

Presentation Layer

특징: 외부에서 요청이 들어오는 계층

어떻게 테스트를 하면 좋을지: 외부 파라미터에 대한 최소한의 유효성 검증을 진행하자. 하단 레이어는 모킹 처리하자. 진행하려는 유효성 검증이 어느 계층에서 검증해야 하는지 잘 생각해보자.

Day 18

@Mock, @MockBean, @Spy, @SpyBean, @InjectMocks 의 차이를 한번 정리해 봅시다.

Mock: Mockito 단위 테스트에서 사용, 아무것도 지정하지 않으면 아무일도 일어나지않음. 행위를 검증

MockBean: Spring Boot 테스트에서 사용, 스프링 컨테이너의 Bean을 목 객체로 교체

Spy: 실제 객체를 기본으로 사용하고, 일부를 stubbing 가능

SpyBean: Spring Boot 테스트에서 사용, 스프링 컨테이너의 Bean을 스파이 객체로 교체

InjectMocks: 테스트 대상 객체에 @Mock, @Spy 객체들을 자동으로 주입

아래 3개의 테스트가 있습니다. 내용을 살펴보고, 각 항목을 @BeforeEach, given절, when절에 배치한다면 어떻게 배치하고 싶으신가요? (@BeforeEach에 올라간 내용은 공통 항목으로 합칠 수 있습니다. ex. 1-1과 2-1을 하나로 합쳐서 @BeforeEach에 배치)

개인적으로 테스트 환경의 독립성, 테스트 간 독립성을 보장하기 위해서 합치고 싶지 않습니다.

모든 테스트에서 setUp 데이터를 사용할지라도, 나중에 추가될 테스트에서 해당 데이터를 사용할지 확신할 수 없고,

또한 setUp에서 데이터를 만드는 것은 이 데이터가 어떤 테스트에서 필요한 것인지 명확하게 표현하지 못하는 것 같기 때문입니다.

AfterEach로 데이터를 비워준다면 고려해볼 수는 있겠지만, 현재로서는 setUp에 합치는 방식이 적절하지 않다고 생각합니다.

끝났다.

테스트 코드에 지레 겁을 먹지않게 해준 시간이었다.

우리 모두 파이팅