xor eax, eax

테스트 중인 클래스에서 이미 한 메서드의 로직을 검증했음에도 이곳 저곳에서 많이 불려서 쓰이는 경우에 해당 메서드를 모킹하여 복잡도를 줄일 수 있다. 해당 방법은 Partial Mocking이라 불리며 Spy Bean을 이용하는 방법이다. 테스트 대상을 해당 어노테이션의 순서에 맞게 설정한다.(반드시 Spy가 먼저 와야 한다.) @Spy @InjectMocks SellerService sellerService; @Spy와 @InjectMocks를 같이 쓰는건 위험하지 않을까? Each annotation has different purposes and they don't step on each other clearly as long as you need to use partial mocks. (a.k.a..

LocalDateTime이나 UUID, Random 등을 이용하는 경우 robust한 테스트를 위해서 값을 고정시킬 필요가 있다. 하지만 기본적으로 제공하는 mockito-core에서는 static 오버라이딩을 지원하지 않기에 다음과 같은 방법이 필요하다. Dependency static 메서드를 사용하기 위해 다음 dependency를 추가한다. (2022/06/19일 기준 4.6.1이 최신 버전이다.) 만약 아래의 디펜던시를 추가하지 않고 static 메서드를 모킹하려는 경우 다음과 같은 에러 메시지를 만날 것이다. The used MockMaker SubclassByteBuddyMockMaker does not support the creation of static mocks Mockito's in..

유닛 테스트 네이밍 컨벤션 테스트 네이밍 컨벤션을 따르는 것은 다른 코드 작성시의 컨벤션을 따르는 것만큼이나 장기적인 프로젝트를 진행하는데 중요하다. 널리 알려진 네이밍 컨벤션을 테스트에 적용함으로써 테스트의 이름만으로 어떤 테스트인지 이해할 수 있게 한다. 적절한 이름을 짓는 것은 어떠한 시도 적절히 번역할 수 없다는 점에서 시와 같다. ~W.H. Auden 네이밍 컨벤션을 선정하기 이전에 그 테스트가 왜 필요한지 테스트의 목적은 무엇인지 먼저 생각해보아야 한다. 테스트 네이밍을 하는데 다음과 같은 몇 가지 추천 방법이 있다. 테스트명은 특정한 필요조건을 명시해야 한다. 테스트명에는 기대되는 인풋이나 상태와 그에 상응하는 결과값을 포함시킬 수 있다. 테스트명은 워크플로우와 아웃풋을 명시하는 선언이나 사..

여태까지 공부하면서 테스트 코드가 가장 어려웠다. 테스트 자체가 어렵다기 보다는 명확하게 잘리지 않은 경계선을 명확하게 잘라내고 구분지어서 '딱 여기서부터 여기까지만. 나머지는 전부 그렇다고 쳐'의 논리 과정을 갖는 것이 쉽지 않았다. 테스트를 이해하는 데에만 시간을 꽤 많이 쏟은 것같은데 오늘 드디어 어느 정도 이해한 느낌을 받아 내용을 정리하고자 한다. 본인이 말하고자 하는 테스트란 유닛 테스트에 한하여 말한다. 유닛 테스트만 할줄 알면 통합 테스트는 식은 죽 먹기라는 말을 본 적이 있는데 그 말에 매우 동의한다. 기본 개념 스프링 내에서 혼자 살아가는 객체는 어느 무엇도 없다. 모든 객체가 크고 작은 요구를 다른 객체에게 해가며 특정 인풋에 대해 특정 액션을 하여 특정 아웃풋을 낸다. 특히 IoC로..