워밍업 클럽 2기 BE 클린코드&테스트 발자국 4주차

강의 : Practical Testing: 실용적인 테스트 가이드

@Mock

• 객체가 기대하는 행위와 리턴 값을 지정하여 테스트에서 기대하는 동작만 테스트가 가능하다

• 주로 외부 네트워크를 사용하는 객체에 사용하면 좋다

   

@MockBean

• 스프링 컨테이너에서 사용하기 위한 @Mock 객체

@Spy

• 일부는 Mock 객체처럼 동작만 그 이외에는 실제 객체처럼 동작한다

• 내가 지정한 동작을 기대하는 행위, 반환에 대한 mocking 할 수 있다

• 실제로 많이 쓰이지는 않는다

@SpyBean

• 스프링 컨테이너에서 사용하기 위한 @Spy 객체

@InjectMocks

• Mock, MockBean 객체를 주입 받는 대상 객체에 사용된다

• ex) OrderService에 UserService, ProductService 주입이 필요한 경우

   

BDDMockito

• given, when, then 3단계로 테스트 작성이 가능하다

Classicist vs Mockist

• 클래스를 직접 사용하여 테스트할지? Classicist

• 관심사 외엔 다 목킹하여 테스트할지? Mockist

• 정답은 없지만 개인적인 내 생각으로는 객체간의 협력에 따른 결과가
  어떤 결과가 나올지 예상 불가하기에 최대한 실제 객체를 사용하는 Classicist가 좀 더 좋아보인다

• 뭐가 정답이라기 보다는 관심사에는 Classicist, 관심사가 아닌 부분엔 Mockist을 적절하게 배치하는게 좋아보인다

한 문단에 한 주제

• 테스트 또한 문서의 성격을 띄기 때문에 하나의 테스트에 한 가지 기능만 테스트해야 가독성 좋다

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

• 어떤 환경이던, 어떤 순서로 실행하던 반복가능하며, 테스트가 성공으로 떠야 한다

테스트 환경 통합

• 테스트 환경을 빠르게 하기 위해서는 ApplicationContext가 띄우는 횟수를 줄여야 한다

• layer별로 상위 클래스를 만들고 그 상위 클래스를 상속하는 방식으로 ApplicationContext를 재사용하자

private 메서드의 테스트?

• public 함수 호출 시 내부 private 메소드도 호출되기에 따로 작성 필요없다

• private 메서드의 테스트가 강력하게 필요하다 느끼면 그건 클래스 분리의 신호!!