ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 구조 리팩토링 - 테스트 DB 분리, 메시지 분리
    개발로그/오늘뭐먹지 프로젝트 2022. 10. 19. 01:27

    1. 테스트 DB 분리

    2. 메시지 분리

     

     

    테스트 DB 분리

    테스트에는 중요한 원칙이 두가지가 있다.

    1. 테스트는 다른 테스트와 격리해야 한다.

    2. 테스트는 반복해서 실행 할 수 있어야 한다.

     

     이 중에서 첫 번째 조건은 잘 지키고 있었지만 두 번째 조건인 반복 실행에서 문제가 있었다. 메인 데이터 베이스를 하나만 사용하기에 기존 데이터 베이스에 있는 데이터들이 테스트에 방해가 되고 있었다. 즉 테스트가 원래 코드와 완전히 분리가 되지 않은 상황이라 어찌 해결할지 고민했었다.

     

     해결책을 몇 가지 알아봤었는데 Test DB를 아예 분리하여 사용하는 방법이 마음에 들었고, 이 방법을 알아봤다. 몇 가지의 방법이 있었는데, 첫 번째로는 그냥 말 그대로 지금 사용하는 mariaDB에 새로운 데이터 베이스를 사용하는 것이고, 두 번째로는 Embedded DB를 설정하여 메모리 내에서 테스트가 가능하도록 진행하는 방법이였다. 이 중 두 번째 방법을 사용하려고 알아봤다.

     

    하지만 문제가 있었는데 MariaDB의 경우 스프링이 Embedded 형태를 지원하지 않는다는 것이였다.

     

    지원 DB: H2, HSQL, Derby - https://docs.spring.io/spring-boot/docs/current/reference/html/data.html#data.sql.datasource.embedded

     

     때문에 Embedded DB를 사용하고자 하면 라이브러리를 사용해서 종속성을 추가해야하는데 그렇게 하고 싶지는 않아서 새로운 TestDB를 생성하는 방향으로 진행했고, 테스트를 진행했다.

     

     

    DB 생성
    테스트 성공

     

     

     


    메시지 분리

     

     

    HTML의 메시지
    RegisterForm DTO

     기존 프로젝트의 경우 메시지가 한곳에 모여있지 않고, 이곳저곳 퍼져있었다. 이는 나중에 변경 사항이 있을 때 모든 HTML코드나 에러 메시지등을 들어가서 확인해야하기에 불편할 것으로 예상되었고, 메시지를 한 파일에 모아 관리하기로 결정했다. 그러기 위해서 MessageSource에 관한 Config를 진행하고, Yaml로 해당 메시지 파일들을 관리하기로 결정했다. 

     

     

    @Configuration
    class MessageConfig {
    
        @Bean
        public MessageSource messageSource() {
            ResourceBundleMessageSource messageSource = new ResourceBundleMessageSource();
            messageSource.setBasenames("messages", "errors");
            messageSource.setDefaultEncoding("utf-8");
            return messageSource;
        }
    }

     

     다음과 같이 설정을 진행하고, 각각 messages.yml, errors.yml로 파일을 만든 뒤 실행하니 프로그램이 메시지를 찾지 못하는 현상이 발생했다. 구글링해보니, 현재 스프링 부트의 messageSource는 .properties는 인식하지만 .yml은 인식하지 못하고, 따로 라이브러리를 추가해야 한다고 한다. 이걸로 종속성을 늘리고 싶지는 않아 yaml은 포기하고 .properties를 이용해 진행했다.

     

    messages.properties
    errors.properties
    html등에 적용

     

     

     

    이렇게 메시지등을 적용했고, 정상적으로 동작하는 것을 확인했다. 

     

     

     참고로 메시지를 해석하는 MessageCodesResolver가 메시지를 생성하는 전략은 다음과 같이 생성하고, 우선순위에 따라 적용한다.

    1. messageCode.Object.field
    2. messagecode.field
    3. messagecode.java.lang.type
    4. messagecode

     스프링의 기본 Bean Validation 객체인 DefaultMessageCodesResolver에서 DTO등에 적용한 @NotBlank등은 다음과 같이 적용된다.

     

    @NotBlank

    NotBlank.Object.field

    NotBlank.filed

    NotBlank.java.land.String

    Notblank

     

    @Range

    Range.item.price

    Range.price

    Range.java.lang.Integer

    Range

     


     

     

     

     

    '개발로그 > 오늘뭐먹지 프로젝트' 카테고리의 다른 글

    JPA 초기화 전략  (0) 2023.01.05
    Selenium을 이용한 크롤링  (1) 2022.12.23
    CI/CD  (1) 2022.04.06
    AWS 배포  (0) 2022.03.31
    메인 기능 구현 완료  (0) 2022.03.10

    댓글

Designed by Tistory.