게시판의 세부적인 기능을 구현한다. 게시판의 기능 구현을 하기 전, 테스트를 진행해서 원하는 기능이 제대로 수행을 해주는지를 판단해야하므로 이 테스트를 진행한다.
루트경로에 service 디렉토리를 만들어서 ArticleService.java를 생성 그리고 테스트 파일도 만들어서 테스트를 정의한다.
이번에는 mockito를 사용해서 진행한다.
mockito는 Mock 객체를 쉽게 만들고, 관리하고, 검증할 수 있는 방법을 제공하는 프레임워크이며 여기서 Mock은 진짜 객체와 비슷하게 동작하지만, 프로그래머가 직접 행동을 관리하는 객체이다.
게시판 서비스에서 자연스럽게 들어갈만한 디펜던시를 미리 붙여서 작성한다. articleservice는 ArticleRepository를 사용하기 때문에 추가한다.
테스트에서는 테스트 해야할 클래스를 불러오고 내가 원하는 기능이 잘 작동하는지 테스트를 작성한다.
검색 + 페이지네이션
게시글을 검색하면, 게시글 리스트가 나타나는가? 이전의 테스트들은 리포지토리의 crud기능,API에서 테스트용으로 DB에 추가된 데이터를 잘 조회하는지의 테스트, 아무튼 생성된 게시판 페이지의 뷰, 게시글 페이지의 뷰, 그리고 로그인 페이지의 뷰 테스트이다. 이제는 사용자가 원하는 데이터를 찾기위한 데이터를 넣었을 때, 정말로 그에 맞는 게시글 리스트가 나타나는지를 테스트 하는 것이다.
searchArticles의 파라미터조건을 통해 조회된 결과를 Dto에 list형태로 담아진 결과물을 articles로 선언, 그 결과물을 assertion 해서 보여주는 작업이 성공하는가를 알아보는 것이다.
이를 위해 루트경로에 dto 패키지를 생성하고
SearchType를 만들기 위해서 루트 도메인 경로에 type이라는 패키지를 생성했다.
ArticleService에서 searchArticles 메소드를 만들어주면 간단한 테스트 준비는 끝난다.
지금 테스트를 돌려보면 성공은 하지만, 지금의 테스트 내용은 null인지 not null인지를 판단하는 정도밖에 되지 않기 때문에 테스트에 살을 더 붙여야한다. 일단 나머지 항목들의 테스트 내용을 추가한 뒤에 구현한다.
페이지네이션의 경우 게시글 리스트를 반환할때 리스트가 아니라 Page로 보내주면 된다.
따라서 searchArticles가 Page를 반환하게 하기 위해서 searchArticles의 내용을 수정한다.
public Page<ArticleDto> searchArticles(SearchType title, String search_keyword){
return Page.empty();
}List 대신 Page로 변경해서 이제 Page로 반환이 되는것이다.
물론 테스트의 ArticleDto또한 Page로 변경한다.
// When
Page<ArticleDto> articles = sut.searchArticles(SearchType.TITLE, "search keyword"); // 제목, 본문, ID, 닉네임, 해시태그게시글 페이지로 이동
홈버튼 -> 게시판 페이지로 리다이렉션
서비스 로직의 기능 보다는 컨트롤러 로직으로 보고 루트 controller에 MainController를 하나 만들어서 테스트도 작성했다.
MainController.java
루트 페이지로 매핑을 하면 루트페이지를 articles 페이지로 리다이렉션 한다.
MainControllerTest.java
루트페이지를 호출할때 리다이렉션이 이루어지는가?를 확인한다.
정렬 기능
이 기능 또한 검색 기능 테스트에서 확인 할수 있다. Page와 Slice로 확인이 가능한데, 검색 기능 테스트를 확장시키면 구현이 가능하기때문에 추가적으로 테스트를 작성하지 않는다.
이 과정에서 중요한 것은 비즈니스 로직의 테스트 코드를 작성할때 어떤 방식으로 출발하는지를 공부하는 것이다. 비즈니스 로직을 시작해서, 테스트 코드를 구상하고, 이때 스프링 부트, 슬라이스 테스트를 사용하지 않고, 애플리케이션 콘텍스트가 나타나지 않고, 필요한 의존성은 mocking하는 방식으로 접근해서 가능한 빠른 테스트를 실행 할수 있게끔 했다는것이 이번 과정의 중요 포인트이다.
