자 이번엔 save에 이어 findAll 함수 테스트를 해보겠다.
근데 save와는 다르게 findAll은 던질 데이터가 없다. 그리고 Transactional로 먼저 입력된 데이터는 롤백되어서 데이터가 없다.
그렇기에 미리 반환받을걸 예상하는 데이터를 만들어 놓는다. 여기까지가 given
when에는 get방식으로 호출할거니 이렇게 적고 반환될걸로 예상되는 마임타입만 accept부분에 적어준다. 그리고 기대하는게 내가 데이터 stub을 2건을 만들었으니, "$", Matchers.hasSize(2) $는 전체를 가리키고 Matchers.hasSize(2)여기에 몇건인지,
그리고 다 입력하고 find_All테스트 요 부분 블럭 씌워서 우클릭 runas - Junit test를 누른다.
테스트에 성공하였다. 이제 이걸 그대로 들고 통합컨트롤러테스트로 가자.
통합테스트에서 given부분은 필요 없으므로 지우는데 지금 데이터베이스에 데이터가 없어서 0건이다.
그래서 위쪽에
@Autowired
private BookRepository bookRepository;이렇게 repository를 DI하고 실제로 DB에 넣어서 확인해 볼 수 있다.
아까 했던거 다시 입력하고 bookRepository.saveAll(books);로 한방에 두개 데이터를 넣어보자. 이러면 이제 2건 들어가고 when에서 /book을 부르고 검증을 할 수 있게 된다.
여기에 한 건 더 넣고 findAll테스트만 돌려봤는데 왼쪽 아래 컬렉션의 크기가 달라서 에러가 발생했다.
이렇게 제대로 바꿔주면 테스트 통과가 뜬다!
근데 여기서
이렇게 id에 null을 넣어도 autoincrement전략에 의해 숫자가 자동으로 1,2,3으로 들어간 것을 볼 수 있다. 자 그럼 여기서 find_All테스트 하나가 아닌 아까 만든것까지 2개를 통째로 테스트하면?
1,2,3이 아니라 2,3,4로 id가 들어간 것을 볼 수 있다. 위에 save테스트()를 하고나서 트랜잭션에 의해 데이터는 롤백이 됐는데 id가 2부터 시작을 한다.
그럼 여기서 아래 사진과같이 find_All테스트()에 andExpect(jsonPath("$.[0].id").value(1L))이렇게 0번지에는 id가 1L일것을 예상한다고 쓰면 ?
find_All테스트()만 돌릴 경우 테스트가 통과를 하겠지만 전체로 돌리면 통과하지 못할것이다.
그럼 이걸 완전히 독립적으로 분리시켜야하는데 이렇게 하기 위해 필요한것이
@BeforeEach 이 어노인데 이건 모든 테스트함수가 실행되기 직전에 각각 실행된다. 즉 save테스트 실행되기 전에 한번 실행되고 find_All실행되기 전에 한번 실행되는 것.
JPA는 EntityManager라는 인터페이스의 구현체이다.
executeUpdate()는 jsp배울때도 preparedstatement 할때 썼던 것이다. 결국 얘도 preparedstatement이런거의 구현체인 셈이다. 아무튼 이렇게 코드를 작성하면 매 테스트를 실행하기 직전에 auto_increment를 1로 초기화하게 된다. 이 증가 전략은 사용하는 DB에 맞게 초기화시켜야한다.
두 테스트 모두 성공 했고, id도 둘다 1부터 시작한다.
이제 id로 데이터 한건 조회하는걸 테스트해보자
코드도 전체 조회하는거랑 비슷하게 쓰고 바로 테스트를 해봤더니,
깔끔하게 통과.
get("/book/{id}",id) 이 부분에서 알 수 있듯이 Pathvaliable처럼 저렇게 지원도 해준다.
이번 게시글은 여기까지
이 글은 유튜브 메타코딩 채널의 영상을 보며 공부한 내용을 기록한 게시글입니다.
