티스토리 뷰

월요일부터 작업을 시작한 ims Project 기능 중 회원가입 기능 구현을 완료했다.



작은 기능이었고, 앞으로의 발전과 나의 도전 정신을 위하여 DTO와 Test를 적용했는데,

당장 atdd를 바로 구현하려니 시간이 너무 오래 걸렸고, 가장 중요한 것은 어떻게 접근해야 할지 감을 잡을 수가 없었다.

그래서 일단 익숙해지겠다는 생각으로 마스터의 코드와 구글의 검색을 통해

단위테스트라고 보는 게 사실상 맞는 test code를 구현하고, 통과하도록 진행했다.



이제 평소처럼 어떤 식으로 작업했는지 정리해보자.

graphQl project와 큰 차이는 없는 userClass이다.

@NoArgsConstructor은 파라미터가 없는 기본 생성자를 생성해주는 어노테이션이고,

혹시 특정 예외가 생겨 추가적인 생성자가 필요한 상황을 대비하여 파라미터가 들어가는 생성자는 직접 생성했다.

또 다른 점이라면 `AbstrachEntity 라는 Class를 상속받는다`는 것인데 이 내부를 들어가면

위의 사진처럼 자동 생성 전략을 설정해둔 primary key 변수가 선언되어 있다.

사실 이 코드는 마스터께서 생성하셨던 코드를 보고 생성한 것인데, 과거 학원에서 step를 진행할 때,

primary key가 온갖 Entity에 중복되는 것을 볼 수 있었다.

중복 제거에 좋은 방법이라 생각해서 적용했고, 대신 마스터의 코드와는 다르게

@Data와 @NoArgsConstructer 어노테이션을 설정하여 메서드 일부를 생략하도록 하였다..

 

이 Class를 적용하면서 @MappedSuperclass와 @EntityListeners(AuditingEntityListener.class) 라는 생소한

어노테이션을 접할 수 있었다.

 

일단 처음으로 @MappedSuperclass를 알아보자.

맨 처음엔 검색하지 않고 Mapped, Super, Class 이렇게 나눠서 어떤 역활을 하는지 잠시 고민해봤다.

Mapped => 매핑 // Super => 부모 class에 있는 생성자를 호출하는 것 // Class는 Class

조합하면 매핑하는 생성자를 호출해서 넣어주는 Class?...

자세히 작성하려하니 너무 글이 길어지고 나중에 다시 읽었을 때

찾기 힘들 듯 하여 이 부분에 대해서는 따로 보겠다.

다시 코드로 돌아와서 이번에는 내부 로직을 구현 후 test code를 구현하였기 때문에

평소처럼 userService Class를 생성하였다.


UserRepository는 기존의 생성했던 것과 그다지 차이가 없으니 생략하고, 본격적으로 test code를 정리해보자.

테스트 케이스 내의 동작을 유연하게 추가하거나 재정의할 수 있는 목적으로 만들어진

@Rule를 이용하여 JUnitSoftAssertions를 선언하였다.

JUnitSoftAssertions에 대해서는 구글로 찾아봤으니 마땅한 정의된 것이 없어서 아직 어떤 기능을 하는지 모르겠다.

 

다만 web Test code 작성 시 겹치는 몇몇 Class의 중복 제거를 위해 생성하였고, 필요한 Class에서 상속하도록 하였다.

한마디로 "일단 있는 걸로 하고" 로 설명할 수 있는 @Mock 을 이용해 Repository를 설정하였다.

@InjectMocks으로 UserService Class를 선언해줬는데

전에 공부한 Inject 와 Mock을 나뉘어 따로 접근하여 합치니 쉽게 알 수 있었다.

Mock으로 설정한 Repository를 UserService에 의존 관계를 설정해주는 것이다.



when을 이용하여 userRepository에 findByUserId(데이터) 가 들어가면 userDto._toUser() 반환하도록 하였고,

다음으로 assertThat을 이용하여 findByUserId에 "a"와 userDto._toUser()가 같은 객체인지를 확인하였다. 



여기서 한 4시간 정도 삽질을 하였는데 findByUserId의 반환 값은 User지만

when(userRepository.findByUserId(userDto._toUser().getUserId())).thenReturn(Optional.of(userDto._toUser()));

설정하여 Optional에 한번 감싸여 있는 User를 반환하게 했기 때문에 반환 타입 오류가 났었다.

맨 마지막에 주석처리 해놓은 것은 삽질의 흔적이라 남겨놨다.



test는 잘 통과했고, 다음은 회원가입에 대한 구현을 진행하겠다.

 

- 회고 -

수요일 밤에 코드 리뷰를 받고, 지금 약 3일이 지나서 글을 작성하였다.

여러 가지 많이 일이 겹쳐서 늦어졌는데, 이번에 깨달은 것은 확실히 어떤 기능을 알고 싶을 때,

이름의 의미를 아는 것이 중요하다는 걸 느꼈다.

예를 들면 Inject가 있을 텐데 물론 같은 이름, 다른 방식이 있을 수 있으니 한번 찾아보긴 해야겠지만

그래도 이런 기본적인 게 하나하나 쌓여가다 보면 처음 보는 것을 보더라도

한번 추측해보고 찾아보는 재미가 있을 것 같다.

 

또 여전히 오타라던가 return 타입 실수가 있지만 

이런 삽질 덕분에 어디서부터 찾아봐야 할지를 조금씩 알아가는 것 같다.

'개발 일지 > <Project> restAPI-ims' 카테고리의 다른 글

Domain 지식과 소통에 대한 고찰  (0) 2019.05.09
회원 정보 수정 mapping error  (0) 2019.04.25
restAPI 설정  (0) 2019.04.15
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함