어제 목표 & 오늘 완료한 한 일
- 알고리즘 문제
- 자바 종합 문법 복습 (3주차)
- 스프링 기초 개인과제 해설 강의
스프링 심화 과제
내일 목표
- 알고리즘 문제
- 자바 종합 문법 복습 (3주차)
- 스프링 기초 개인과제 해설 강의
- 스프링 심화 과제 (테스트 코드 작성)
느낀점 & 오늘 공부한 내용
SignupRequestDto 테스트를 진행하기 위해 코드를 작성하려고 했지만 코드를 살펴보니 'DTO에서 유효성 검사에 대해 테스트를 할 수가 있나..?'라는 생각이 들었다. 그래서 서치해본 결과, 해당 블로그(https://velog.io/@tigger/DTO-%EA%B2%80%EC%A6%9D-%EB%B0%8F-%ED%85%8C%EC%8A%A4%ED%8A%B8)를 참고해 문제를 해결할 수 있었다. 해당 블로그에서는 Validator라는 인터페이스를 통해 dto 테스트를 했다.
Validator는 인터페이스로, 스프링에서 이를 이용해 별도의 검증용 Spring Bean을 만들어 beam 인스턴스의 유효성을 검사한다고 한다.
@Test
@DisplayName("유효성 검사 : 성공")
void test1() {
// given
String username = "user12345";
String password = "Spring03";
// when
requestDto = new SignupRequestDto(username, password);
Set<ConstraintViolation<SignupRequestDto>> violations = validator.validate(requestDto);
// then
assertEquals(0, violations.size());
}
Validator를 사용해 테스트 코드를 작성하였는데 여기서 검증에 실패한 데이터에 대한 정보는 ConstraintViolation에 담긴다고 한다. 그래서 성공 테스트의 경우 violations.size가 0이면 정상적으로 동작을 한다는 것을 의미한다.
만약 아이디 입력이나 비밀번호 입력에서 조건을 만족하지 않는 데이터를 입력받았다면 violations의 size는 1이되고, 둘 다 잘못되었다면 그 크기는 2가 된다.
아래는 아이디를 조건에 맞지 않게 입력하였을 경우의 테스트 코드이다.
@Test
@DisplayName("유효성 검사 : 잘못된 아이디 입력으로 실패")
void test2() {
// given
String username = "user";
String password = "Spring03";
// when
requestDto = new SignupRequestDto(username, password);
Set<ConstraintViolation<SignupRequestDto>> violations = validator.validate(requestDto);
for(ConstraintViolation<SignupRequestDto> violation : violations) {
System.out.println(violation);
}
// then
assertEquals(1, violations.size());
}
이 경우에는 검증에 실패한 데이터가 있기 때문에 이에 대한 정보는 violations에 값이 담기는데, 제대로 된 정보가 담기는지 궁금해 출력을 해봤다.
그 결과, 올바른 정보가 출력되는 것을 볼 수 있었다.
Entity 테스트를 추가하기 위해서 코드를 작성하는데 내가 작성한 코드에서는 엔티티 클래스에서 생성자의 인자로 requestDto와 user등을 받는다. 그 말은 requestDto에 초기화 값을 넣어줘야 Entity 테스트를 진행할 수 있다는 것이다. 그런데 코드를 작성하던 중, '테스트를 위해서 requestDto에 생성자를 넣는게 맞나?' 하는 생각이 들었다. 그래서 찾아봤는데, 어떤 한 블로그에서(https://cheese10yun.github.io/spring-about-test) 테스트만을 위한 생성자를 작성하는 것은 지양해야하고, 생성자가 필요하다면 테스트시에만 사용이 가능하게끔 @NoArgsConstructor(access = AccessLevel.PRIVATE)와 같은 Default 접근 제어 지시자와 Builder를 이용해 객체를 생성하는 것이 좋다는 이야기하는 것을 봤다. 그래서 이를 토대로 코드를 작성할 예정이다.
'TIL & WIL' 카테고리의 다른 글
[WIL] #12. 231127~231203 (0) | 2023.12.03 |
---|---|
[TIL] #81. 231203 (0) | 2023.12.03 |
[TIL] #79. 231201 (1) | 2023.12.01 |
[TIL] #78. 231130 (0) | 2023.11.30 |
[TIL] #77. 231129 (0) | 2023.11.29 |