개발은 나를 포함한 두명이 서버 개발을 진행하게 되었고, 도메인별로 나누어 진행하게 되었다.
내 담당중 하나인 Post에 대한 부분 개발을 진행하기에 앞서, TDD 적용을 위해 어떤 기능적 요구사항들이 있는지 분석하게 되었다.
우선 Home 화면부터 분석해본다.
최상단의 캐러셀에는 다음 인터뷰 할 개발자에 대한 예고 포스트가 나타난다.
나타나는 정보로는 카드의 우상단 좋아요(하트), 북마크, 제목, 내용, 해시태그가 있다.
하단에 내려오면 Question과 Community로 나뉘어 핫토픽을 볼 수 있다.
그 아래에 하나의 게시글에 대한 해시태그, 제목, 내용, 작성자, 북마크, 댓글 수, 사진을 볼 수있다.
그리고 하단의 More 버튼을 누르면 해당 게시판으로 이동한다.
홈 화면에 대한 기능을 정리해보면
예외 처리 부분에 있어서는 이렇게 목록을 가져오는 것 보다 게시글 작성 부분이 더 많은 처리가 필요할 것으로 생각된다.
우선은 홈 화면에 맞게 테스트 코드를 작성해보고자 한다.
그럼 잠시 켄트 벡에 빙의해서 테스트 코드를 작성해보자.
켄트 벡 씨는 도메인 설계마저 테스트를 작성한 후에 진행했지만 나의 경우 기획자, 파트너 개발자와 함께 도메인에 대해 논의를 하고 디비 설계를 마친 상태이니 도메인을 먼저 생성한 정도는 켄트 벡 씨가 봐줄거라 믿으며 진행하겠다.
우선 우리에게 필요한 건 상단 캐러셀의 내용을 가져오는 부분이다.
캐러셀에 대한 부분은 Interview domain에 해당하는 부분이다.
인터뷰 서비스 테스트에 우리가 원하던 요구사항을 적어넣어 보았다.
아직은 10개의 테스트밖에 없지만 분명 구현하다보면 아차! 하는 부분이 나와 테스트가 더 늘 거라고 필히 생각한다.
그럼 테스트 코드부터 하나하나 작성해보자!
우선 가장 먼저 캐러셀에서 보이는 인터뷰 게시글에 대한 부분부터 테스트를 만들어보자.
캐러셀에 제목, 컨텐츠를 가져올 수 있으면 된다.
인터뷰 출력을 하려 하니 우선 작성하는 코드가 필요하다. 그래서 작성하는 테스트를 먼저 작성하기로 했다.
그런데 작성하는 코드를 작성하기 전에 우선 우리에겐 User가 필요하다.
그럼 일단 테스트 클래스 안에 createUser를 만들어주어 임시 User를 만들어주자.
우선 UserDomain 안에서 생성자와 생성 메서드를 통해 테스트 유저를 만들 수 있도록 변경해주자.
private User(String userName, String userId, String email, String intro) {
this.userName = userName;
this.userId = userId;
this.email = email;
this.intro = intro;
}
// == 생성 메서드 == //
public static User createTestUser(String userName, String userId, String email, String intro){
return new User(userName, userId, email, intro);
}
그럼 테스트 클래스 안에 유저를 생성할 수 있게 해 주자.
private User createUser() {
User user = User.createTestUser("userA", "test", "test@test.com", "test intro");
em.persist(user);
return user;
}
이렇게 하나의 빨간 불을 없앴다. 야호!
그럼 두 번째 빨간불인 createInterview의 불을 없애기 위해 createInterview를 만들어주자.
하지만 이 createInterview는 given절에 있다.
우리는 이 createInterview를 위한 새로운 테스트를 만들어주어야 한다!
createInterview에 대한 예외 사항의 테스트도 제작해야하지만 일단은 넘어가서 빨간 막대를 초록 막대로 변경하고 뒤에 처리하기로 하자! 그저 우리는 체크 리스트에 적어두기만 하면 된다!
그럼 우선 createInterview를 만들어보기로 하자.
우선은 interviewService를 만들어야한다!
우리에겐 intelliJ가 제공하는 option + enter라는 기능이 있으니 적극 활용한다.
다음과 같이 에러가 발생한다.
우리는 Spring Data JPA를 사용할 것이니 Repository Interface를 만들어주자.
그럼 다음처럼 에러가 사라지는 걸 볼 수 있다.
Spring data jpa가 제공하는 interface의 기본 메서드들은 굳이 테스트를 진행하지 않아도 되기 때문에 기본 메서드에 대한 테스트는 넘어간다.
그럼 이제 다시 테스트 코드로 넘어가보자.
다음과 같이 에러가 사라진 걸 볼 수 있다.
그럼 원래 진행하려 했던 인터뷰 게시글 출력 부분으로 넘어가보자.
우리에게 남은 건 findInterviewByCreatedDate를 구현하는 것이다.
다음처럼 구현하고 생각해보니 테스트에서 최근의 인터뷰 하나만 가져올 수 있도록 테스트해야겠다는 생각이 들었다.
다음처럼 테스트를 변경하고 실행했다
야호! 녹색 막대가 나타났다!
이로써 우리는 인터뷰 게시글 생성, 게시글 출력에 대한 부분을 마쳤다! (물론 생성에 있어 예외 처리는 남아있다... 하지만 지금 우리의 목표는 홈 화면 출력이지 게시글 생성이 아니므로 그건 차후로 미루자.)
더 두려울게 뭐가 있을까. 이제 위에서부터 차례대로 테스트 코드 작성을 해 보자.
다음처럼 좋아요 개수 카운트를 위한 테스트코드를 작성했다.
우선 interviewLikeRepository와 countByInterview 메서드를 만들어주자.
리포지토리와 메서드를 만들어주고 테스트를 실행하자
야호! 초록 막대가 완성되었다!
이제부턴 조금 빠르게 진행해보자! 테스트를 만들고, 코드를 구현하고, 초록막대를 보는 순이다.
주의할 건 최대한 빠르게 초록 막대를 보고, 리팩토링을 하는 것이다.
좋아!
일단 좋아요 999개 이상 북마크 999개 이상은 프론트에서 처리하기로 했다. 테스트 삭제!
인터뷰 북마크 갯수 카운트는 좋아요 갯수 카운트와 비슷하게 만들자!
역시 초록막대다!
인터뷰를 좋아요 하는 테스트와 코드도 구현 완료!
이걸 구현하다보니 이미 좋아요 된 상태일 때 해제하는 것도 구현해야겠다! 새로 테스트를 만들어주고 구현해주자!
인터뷰 북마크도 이어서 똑같이 테스트 작성 및 구현해준다.
북마크 역시 다시 눌렀을 때의 경우, 내가 눌렀는지 여부 판별까지 넣어서 테스트해 주었다.
다음에는 api를 작성해 프론트에 뿌려주는 작업을 진행하겠다.