유데미 스타터스 취업 부트캠프 2기 - 백엔드(java, 자바) 8주차 학습 일지

첫 번째 스프린트가 마무리 되었다. 어김없이 회고 시작~

첫 스프린트를 끝내고,

이번주 금요일에 데모데이라서 서로 한 것은 통합하고, 앞에서 보여주는 시간을 가졌다. 일단 두 프로젝트 얼추 원하는 기능은 얼추 갖춰진 것 같아 안심이 되면서도, 앞으로 더 열심히 할 필요성을 느꼈다. 지난주와 달리 이번주는 피로함을 조금 느껴졌다. 나 같은 경우에는 어쩌다 보니 프로젝트를 두 개 맡게된 상황인데, 두 개다 잘할 수 있을거라 했던 생각은 나의 자만이 될 수도 있을거 같은 위기감이 든다. 일단 OAuth, 소셜 로그인도 손 쉽게 끝낼거라 호언장담했던 것과 달리 한 주 넘게 소요되었다. 일단 내 부분은 완성이 되었다 생각했지만,, 이후에도 다양한 의견들이 추가되다보니 나도 모르게 조금 날 선 모습으로 반응을 보이게 되었다. 내가 내린 결론이 정답이 아닐 수도 있는데, 갑자기 틀어지려니 그랬던거 같다.

내가 부트캠프에 지원한 이유를 다시 생각해보았다. 팀원들과 여러 키워드를 공유하며, 모르는 것은 취하고 아는 것은 베푸며 함께 성장하는 장을 마련하기 위함이다. 근데 서로 바빠지다보니 우리끼리도 소통이 부족했음을 느꼈다. 서로 아는 것과 모르는 것이 다르다보니 상반될 수 있는데, 이런 것들은 대화를 통해 잘 절충할 수 있도록 해야겠다. git도 더 연습하고,,,

내가 맡은 바는 잘 끝내서 뿌듯하다.

두 번째 스프린트 화이팅!

멘토님 만남

이번에는 오프라인으로 멘토님을 만나 뵈었다. 스프린트가 잘 진행되고 있냐는 물음에 확실한 대답은 할 순 없었다. 그래도 이제 얼추 윤곽들은 잡혀가니 순항(?)할 것이라고 말씀드렸다. 오늘 멘토님이 알려주실 것은 TDD는 어떤 식으로 짜는지 흐름을 보여주시는 거였다

이번 예시는 출석에 관한 것인데, 먼저 출석 체크를 하면서 만날 수 있는 경우의 수를 생각해보는 것이다.

• 정상 출석한 경우
• 지각한 경우
• 지정한 반경을 벗어난 경우
• 로그인을 하지 않았는데 출석 시도하는 경우

대략 이정도가 있을텐데, 이에 맞게 테스트 코드를 준비하는 것이다.

@Test
@DisplayName("로그인 되지 않았는데 출석 시도")
public void checkAttendanceNotLogined() {
    Assertions.fail();
}

@Test
public void checkAttendanceDistinct() {
    Assertions.fail();
}

@Test
public void checkAttendanceOutRange() {
    Assertions.fail();
}

@Test
public void checkAttendanceLate() {
    Assertions.fail();
}

 

메서드 안에 코드를 작성하지 않으면, 정상적으로 수행되어 테스트가 성공하기에 이를 방지하기 위해 만든 코드에는 Assertions.fail()를 넣어 의도적으로 실패하게 만드는 것이다. 이렇게 하면 내가 놓친 부분은 코드를 작성하게 되겠지?? @DisplayName을 달아두면 해당 테스트가 어떤 것인지 손쉽게 명시할 수 있다. 다음과 같이 케이스가 마련되면 이제 서비스 코드를 작성하고, 테스트 코드에 알맞은 값을 삽입하여 테스트하면 된다. TDD는 보통 given, when, then 절로 구상한다.

given은 테스트를 위한 값을 세팅하고, when은 내가 서비스 코드를 돌리고, then은 코드를 돌리 고 내가 의도한 값으로 나오는지 확인하면 되는 것이다. 아래 코드는 멘토님이 대략적으로 짜주신 코드이다.

@InjectMocks
private AttendanceService attendanceService;
@Mock
private UserRepository userRepository;
@Mock
private AttendanceRepository attendanceRepository;

@Test
@DisplayName("유저의 출석체크가 정상적으로 등록된다")
public void attendanceTest() {
    //given
    User user = mock(User.class);
    Generation generation = mock(Generation.class);
    Attendance attendance = new Attendance(null, user, "", null, null);
    when(user.getGeneration()).thenReturn(generation);
    when(userRepository.findById(any())).thenReturn(Optional.of(user));
    when(attendanceRepository.findById(any())).thenReturn(Optional.of(attendance));

    switch (attendance.getStatus()) {

        case PRESENT -> {
        }
        case LATE -> {
        }
        case ABSENT -> {
        }
    }

    //when
    AttendanceDto attendanceDto = attendanceService.checkAttendance(AttendanceCheckDto.of(0D, 0D, LocalDateTime.now()));
    //then

    assertEquals(attendanceDto.getAttendanceStatus(), AttendanceStatus.LATE);
}

@SpringBootTest를 돌려 스프링 컨테이너를 띄우고 의존성 주입을 해줄 수 있다. 하지만, 이 방식을 사용하게 되면 테스트 코드가 많아졌을 때, 시간이 오래 걸리게 될 것이라고 한다. 그래서 Mock 방식을 활용하여 가짜 객체를 삽입해서 활용할 수 있다고 한다.

@Mock 어노테이션을 달아두면 Mock 객체가 만들어지는 것이고, @InjectMocks를 달아둔 서비스에 Mock 객체들을 삽입해주는 것이다. 다음엔 테스트 코드에 given 절에도 Mock User, Generation을 만들 수 있는데, Mock 테스트는 내가 when()으로 무언가 했을 때, thenReturn()을 통해 확정적으로 반환해줌을 의미하는 것이라 이해하면 될거 같다. 가끔은 실제 객체를 만들어 줘야할 때도 있기에 유의하면서 사용해야겠다. 테스트 코드를 짜면 정말 좋지만, 실제 일을 하게되면 시간 관계상 포기를 할 수도 있을 것이라 하셨다. 배포하기도 바쁘니 어쩔 수 없는 부분이라는데, 그래도 가급적이면 내가 능숙해져서 짜볼 수 있도록 노력해봐야 겠다.

이외로 몇가지 피드백을 해주셨다.

DTO라해서 @Data 함부로 달지 말아라.

@Data 어노테이션은 다음의 어노테이션이 들어가있다.
@Getter, @Setter, @RequiredArgsConstructor, @ToString, @EqualsAndHashCode

모두 다 개발자 편의를 위한 어노테이션들인데, 이를 남용 시 발생할 수 있는 문제가 몇가지 더러 있다.

@Setter, 필드에 대한 setter를 만들어 주는 어노테이션인데, 다른 코드에서 남용될 수 있기에 조심.

@ToString, 연관관계 매핑이 걸려있는 곳에 사용하면 무한 순회를 맛봐 서비스가 터지는 불상사가 발생할 수 있다.

웬만하면 @Getter 정도만 쓰고, 필요에 따라 추가 메서드를 기입하는 방식으로 돌려봐야겠다.

@Builder 패턴 사용은 괜찮다.

서비스 코드의 재사용성을 위한 반환 타입을 고려해보기?

내 서비스 코드들은 반환 타입이 BaseResponse<T> 형식이다.

@Data
public class BaseResponseDto<T> {

    private String message;

    private T data;

    public BaseResponseDto(String message, T data) {
        this.message = message;
        this.data = data;
    }
}

message에는 어떤 로직으로 인해 발생한 결과의 내용이 무엇인지 담겨 있고, data안에 결과값이 담길 수도 안 담길 수도 있는 형태이다.
멘토님께서는 서비스 코드는 추후 다른 곳에서도 쓰일 수 있을테니, 반환 타입을 이렇게 해두면 재활용하기 어려울 수도 있을 것이라 하였다.  이러면 테스트 코드에서도 보기 어려울 것이고..? 차라리 BaseResponse로 감싸주는 것은 Controller 코드 정도에서만 하면 괜찮지 않을까 하신다. 이 부분은 관련 내용을 더 찾아봐야겠다.

---

* 유데미 바로가기 : https://bit.ly/3SFlXDy * 유데미 STARTERS 취업 부트캠프 공식 블로그 보러가기 : https://blog.naver.com/udemy-wjtb 본 후기는 유데미-웅진씽크빅 취업 부트캠프 2기 - 프론트엔드&백엔드 과정 학습 일지 리뷰로 작성되었습니다.