테스트/JUnit

    변하는 값을 테스트 하는 방법(LocalDateTime, UUID, Random)

    개발을 하다보면 현재 시간이나, 랜덤 값이 필요한 로직이 분명 필요합니다. 프로젝트를 진행하면서, LocalDate.now()와 UUID.randomUUID 등을 사용해야 했습니다. 하지만 테스트를 할 수가 없는 문제가 발생하였습니다. 모임 엔티티의 생성 조건과 참여 조건의 요구사항은 다음과 같습니다. 모임 시작날짜, 종료날짜는 현재시간 이유여야만 한다. 종료날짜 이후에는 참여하지 못하고 예외가 발생하게 된다. 이 때, 종료 날짜는 무조건 현재날짜 이후에만 지정 가능하고, 현재 요청한 시간은 항상 endDate 이므로 만약 endDate가 3월 16일이고, 3월 15일날 테스트를 하게된다면 항상 통과할 수 밖에 없게 되어 모임 가입이 불가능한 테스트를 할 수 없게 됩니다. public class Book..

    JUnit5 리스트가 정렬 조건에 맞게 정렬되었는지 검증하는법

    List가 특정한 기준으로 정렬할 때 보통, Comparator 인터페이스를 사용하여 정렬 기준을 지정한다. // List를 정렬할 Comparator Comparator comparator = (s1, s2) -> s1.compareTo(s2); // List를 정렬 List list = new ArrayList(); list.add("apple"); list.add("banana"); list.add("cherry"); list.sort(comparator); 이제, List가 특정한 기준으로 정렬되었는지 확인하려면, 다음과 같이 assert 메소드를 사용하여 비교하면 된다. // List가 특정한 기준으로 정렬되었는지 확인 assertThat(list).isSortedAccordingTo(compa..

    Mockito Stub 작성 시 주의 사항

    InvalidUseOfMatchersException https://github.com/HomoEfficio/dev-tips/blob/master/Mockito%20Stub%20%EC%9E%91%EC%84%B1%20%EC%8B%9C%20%EC%A3%BC%EC%9D%98%20%EC%82%AC%ED%95%AD.md#mockito-stub-%EC%9E%91%EC%84%B1-%EC%8B%9C-%EC%A3%BC%EC%9D%98-%EC%82%AC%ED%95%AD com.nhaarman.mockitokotlin2.BDDMockitoKt.given https://github.com/HomoEfficio/dev-tips/blob/master/Mockito%20Stub%20%EC%9E%91%EC%84%B1%20%EC%8B..

    Mock vs. Stub vs. Spy

    Mock과 Stub, Spy의 차이점에 대해 알아보기 전에 Test Double에 대하여 먼저 정리해보겠습니다. Test Double 테스트계의 스턴트맨. 영어에서는 Stunt Double이라고 부를 뿐이고, 한국사람들에게 더 익숙한 표현은 스턴트맨입니다. 테스트 코드에서 대역(가짜)을 쓰는 것에 착안하여 이름을 이렇게 지었고, 영화를 찍기 위해 위험한 액션을 대신해주는 것이 스턴트맨이라면 , 테스트를 통과하기 위해 액션을 대신해주는 것이 Test Double입니다. Test Double의 종류 더미 객체 (Dummy Object) Dummy Object는 전달되지만 실제로는 사용되지 않습니다. 일반적으로 파라미터를 전달하기 위한 용도로만 사용합니다. 모의 (Mock) Mock은 메소드를 호출했을 때 사..

    Java Collection, List, Array 비교, 검증

    예제 List List list1 = Arrays.asList("1", "2", "3", "4"); List list2 = Arrays.asList("1", "2", "3", "4"); List list3 = Arrays.asList("1", "2", "4", "3"); JUnit - Assert @Test public void whenTestingForEquality_ShouldBeEqual() throws Exception { Assert.assertEquals(list1, list2); Assert.assertNotSame(list1, list2); Assert.assertNotEquals(list1, list3); } AssertJ - Assertions @Test public void whenT..

    @WebMvcTest Security 401 403 응답 해결방법 - csrf

    @WebMvcTest Security 401 403 응답 해결 @WebMvcTest는 MVC와 관련된 애노테이션(Controller, ControllerAdvice, Filter, WebMvcConfigurer 등..)이 적용된 Bean들만 불러오고, @Component, @Service, @Repository와 같은 Bean들은 불러오지 않는다. https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/test/autoconfigure/web/servlet/WebMvcTest.html 그리고 @WebMvcTest는 Spring Security를 auto-configure 한다 여기서 문제가 되는 것은 직접 구현한 Sprin..

    Mockito Verify, Mock Object 검증, 호출 횟수 검증

    Mockito Verify 메소드는 특정 동작이 발생했는지 확인하는 데 사용된다. mocking한 메서드가 호출되었는지 확인하기 위해 테스트 메서드 코드 끝에 Mockito 검증 메서드를 사용할 수 있다. https://github.com/WebJournal/journaldev/tree/master/Mockito-Examples 에 더 많은 예제가 있다. Mockito 검증 Mockito verify() 메서드를 사용하여 메서드 호출 수 (call count)를 테스트할 수도 있다. mock 메서드에 대해 정확한 횟수, 적어도 한 번, 최대 호출 횟수를 테스트할 수 있다. verifyNoMoreInteractions() : 모든 verify() 메서드 호출 후에 모든 것이 확인되었는지 확인할 수 있다 ...

    MockMvc 테스트시 201 created URI를 검증하는 방법

    현재 ItemController에서는 Resource 생성 시 201 created 응답과 함께 생성된 자원의 URI를 리턴해주고있다. @RequestMapping("/api/v1/items") @RestController @RequiredArgsConstructor public class ItemController { ​ private final ItemFacadeService itemService; ​ @PostMapping(consumes = APPLICATION_JSON_VALUE, produces = APPLICATION_JSON_VALUE) public ResponseEntity createItem(@RequestBody @Valid ItemCreateRequest itemCreateReque..

    MockMvc 테스트 body가 '<no character encoding set>' 인경우

    @WebMvc 테스트 중 Request Body 데이터가 나오지 않는 상황이 발생. MockHttpServletRequest: HTTP Method = POST Request URI = /api/v1/items Parameters = {_csrf=[89d3f355-ea84-4108-b910-eebcb6795735]} Headers = [Content-Type:"application/json", Accept:"application/json", Content-Length:"505"] Body = // Session Attrs = {} Handler: Type = com.prgrms.bdbks.domain.item.api.ItemController Method = com.prgrms.bdbks.domain.i..

    JUnit5 생성자 주입 방법과 원리

    JUnit5 생성자 주입 방법과 원리 앞서 정리한 글 중에서, main 환경이랑 test 환경이랑 환경 자체가 달라서 생성자 주입이 안된다고 하였다. 그래서 대부분 @Autowired로 주입하거나, @BeforeEach로 테스트 시작 전에 직접 주입을 시켜주는 방식을 사용했다. 하지만 스프링 5.2.x 버전 부터 어노테이션을 통한 생성자 주입이 가능해졌다. (또 어노테이션이야?) 그런데 @Autowired 처럼 필드 하나하나마다 어노테이션을 선언하는 것이 아닌 1번만 선언해서 생성자 주입이 가능하다. 바로 @TestConstructor(autowireMode = TestConstructor.AutowiredMode.ALL) 을 사용하면 된다 spring.properties 파일을 통한 @Autowired..