https://school.programmers.co.kr/learn/courses/30/lessons/92334

문제 설명

신입사원 무지는 게시판 불량 이용자를 신고하고 처리 결과를 메일로 발송하는 시스템을 개발하려 합니다. 무지가 개발하려는 시스템은 다음과 같습니다.

• 각 유저는 한 번에 한 명의 유저를 신고할 수 있습니다.
  • 신고 횟수에 제한은 없습니다. 서로 다른 유저를 계속해서 신고할 수 있습니다.
  • 한 유저를 여러 번 신고할 수도 있지만, 동일한 유저에 대한 신고 횟수는 1회로 처리됩니다.
• k번 이상 신고된 유저는 게시판 이용이 정지되며, 해당 유저를 신고한 모든 유저에게 정지 사실을 메일로 발송합니다.
  • 유저가 신고한 모든 내용을 취합하여 마지막에 한꺼번에 게시판 이용 정지를 시키면서 정지 메일을 발송합니다.

다음은 전체 유저 목록이 ["muzi", "frodo", "apeach", "neo"]이고, k = 2(즉, 2번 이상 신고당하면 이용 정지)인 경우의 예시입니다.

유저 ID 유저가 신고한 ID 설명

각 유저별로 신고당한 횟수는 다음과 같습니다.

유저 ID 신고당한 횟수

위 예시에서는 2번 이상 신고당한 "frodo"와 "neo"의 게시판 이용이 정지됩니다. 이때, 각 유저별로 신고한 아이디와 정지된 아이디를 정리하면 다음과 같습니다.

유저 ID 유저가 신고한 ID 정지된 ID

따라서 "muzi"는 처리 결과 메일을 2회, "frodo"와 "apeach"는 각각 처리 결과 메일을 1회 받게 됩니다.

이용자의 ID가 담긴 문자열 배열 id_list, 각 이용자가 신고한 이용자의 ID 정보가 담긴 문자열 배열 report, 정지 기준이 되는 신고 횟수 k가 매개변수로 주어질 때, 각 유저별로 처리 결과 메일을 받은 횟수를 배열에 담아 return 하도록 solution 함수를 완성해주세요.

제한사항

• 2 ≤ id_list의 길이 ≤ 1,000
  • 1 ≤ id_list의 원소 길이 ≤ 10
  • id_list의 원소는 이용자의 id를 나타내는 문자열이며 알파벳 소문자로만 이루어져 있습니다.
  • id_list에는 같은 아이디가 중복해서 들어있지 않습니다.
• 1 ≤ report의 길이 ≤ 200,000
  • 3 ≤ report의 원소 길이 ≤ 21
  • report의 원소는 "이용자id 신고한id"형태의 문자열입니다.
  • 예를 들어 "muzi frodo"의 경우 "muzi"가 "frodo"를 신고했다는 의미입니다.
  • id는 알파벳 소문자로만 이루어져 있습니다.
  • 이용자id와 신고한id는 공백(스페이스)하나로 구분되어 있습니다.
  • 자기 자신을 신고하는 경우는 없습니다.
• 1 ≤ k ≤ 200, k는 자연수입니다.
• return 하는 배열은 id_list에 담긴 id 순서대로 각 유저가 받은 결과 메일 수를 담으면 됩니다.

입출력 예

id_list report k result

풀이

해당 문제는 적절한 자료구조와 문자열 관련 메소드의 활용으로 풀이하면 될 것 같았다.

1차적으로는 해당 회원의 인덱스를 갖고있는 배열이 필요해보였고, 신고 상황을 저장할 배열, 신고 누적 횟수를 저장할 배열, 그리고 이메일 송신 횟수를 갖는 배열 이렇게 4개의 배열을 선언할까 생각했었고,

2차적으로는 인덱스를 해시맵으로 구현, 신고상황은 한 회원이 여러번 같은 회원을 신고할 , 다른 회원을 신고한 기록도 저장해야 하니 해시맵이 아닌 리포트배열은 2차원으로 , 그리고 신고 누적 횟수는 해시맵, 그리고 이메일 배열은 마찬가지로 2차원 배열로 구현하였다 (?)

제출 이후인 3차적으로 생각하면 인덱스와 누적 신고 횟수를 합쳐서 정수 리스트를 같는 해시맵과 신고누적 횟수 해시맵 이렇게 2개만 선언해도 됐을 것 같다.

class Solution {
 public List<Integer> solution(String[] id_list, String[] report, int k) {
    List<Integer> answer = new ArrayList<>();
        HashMap<String,Integer> idxMap = new HashMap<>();
        HashMap<String,Integer> reportedMap = new HashMap<>();
        int[][] reportArr = new int[id_list.length][id_list.length];
        int[][] emailArr = new int[id_list.length][1];
        int idx = 0;
        for(String id : id_list){
            reportedMap.put(id,0);
            idxMap.put(id,idx);
            for(int j=0; j<id_list.length;j++){
                reportArr[idx][j]=0;
            }
            idx++;
        }
        for(String detail:report){
            int spaceIdx = detail.indexOf(" ");
            String reportFrom = detail.substring(0,spaceIdx);
            String reportTo = detail.substring(spaceIdx+1,detail.length());
            int fromIdx = idxMap.get(reportFrom);
            int toIdx = idxMap.get(reportTo);
            if(reportArr[toIdx][fromIdx]!=1){
                reportArr[toIdx][fromIdx]=1;
                reportedMap.put(reportTo,reportedMap.get(reportTo)+1);
            }
        }
        reportedMap.forEach((key,value)->{
            if(value>=k){
                int toIdx = idxMap.get(key);
                for(int i=0; i<id_list.length;i++){
                    if(reportArr[toIdx][i]==1){
                        emailArr[i][0]++;
                    }
                }
            }
        });
        for(int i=0; i<id_list.length;i++){
            answer.add(emailArr[i][0]);
        }
        return answer;
    }
}

https://school.programmers.co.kr/learn/courses/30/lessons/161990

문제 설명

코딩테스트를 준비하는 머쓱이는 프로그래머스에서 문제를 풀고 나중에 다시 코드를 보면서 공부하려고 작성한 코드를 컴퓨터 바탕화면에 아무 위치에나 저장해 둡니다. 저장한 코드가 많아지면서 머쓱이는 본인의 컴퓨터 바탕화면이 너무 지저분하다고 생각했습니다. 프로그래머스에서 작성했던 코드는 그 문제에 가서 다시 볼 수 있기 때문에 저장해 둔 파일들을 전부 삭제하기로 했습니다.

컴퓨터 바탕화면은 각 칸이 정사각형인 격자판입니다. 이때 컴퓨터 바탕화면의 상태를 나타낸 문자열 배열 wallpaper가 주어집니다. 파일들은 바탕화면의 격자칸에 위치하고 바탕화면의 격자점들은 바탕화면의 가장 왼쪽 위를 (0, 0)으로 시작해 (세로 좌표, 가로 좌표)로 표현합니다. 빈칸은 ".", 파일이 있는 칸은 "#"의 값을 가집니다. 드래그를 하면 파일들을 선택할 수 있고, 선택된 파일들을 삭제할 수 있습니다. 머쓱이는 최소한의 이동거리를 갖는 한 번의 드래그로 모든 파일을 선택해서 한 번에 지우려고 하며 드래그로 파일들을 선택하는 방법은 다음과 같습니다.

• 드래그는 바탕화면의 격자점 S(lux, luy)를 마우스 왼쪽 버튼으로 클릭한 상태로 격자점 E(rdx, rdy)로 이동한 뒤 마우스 왼쪽 버튼을 떼는 행동입니다. 이때, "점 S에서 점 E로 드래그한다"고 표현하고 점 S와 점 E를 각각 드래그의 시작점, 끝점이라고 표현합니다.
• 점 S(lux, luy)에서 점 E(rdx, rdy)로 드래그를 할 때, "드래그 한 거리"는 |rdx - lux| + |rdy - luy|로 정의합니다.
• 점 S에서 점 E로 드래그를 하면 바탕화면에서 두 격자점을 각각 왼쪽 위, 오른쪽 아래로 하는 직사각형 내부에 있는 모든 파일이 선택됩니다.

예를 들어

wallpaper

= [".#...", "..#..", "...#."]인 바탕화면을 그림으로 나타내면 다음과 같습니다.

이러한 바탕화면에서 다음 그림과 같이 S(0, 1)에서 E(3, 4)로 드래그하면 세 개의 파일이 모두 선택되므로 드래그 한 거리 (3 - 0) + (4 - 1) = 6을 최솟값으로 모든 파일을 선택 가능합니다.

(0, 0)에서 (3, 5)로 드래그해도 모든 파일을 선택할 수 있지만 이때 드래그 한 거리는 (3 - 0) + (5 - 0) = 8이고 이전의 방법보다 거리가 늘어납니다.

머쓱이의 컴퓨터 바탕화면의 상태를 나타내는 문자열 배열 wallpaper가 매개변수로 주어질 때 바탕화면의 파일들을 한 번에 삭제하기 위해 최소한의 이동거리를 갖는 드래그의 시작점과 끝점을 담은 정수 배열을 return하는 solution 함수를 작성해 주세요. 드래그의 시작점이 (lux, luy), 끝점이 (rdx, rdy)라면 정수 배열 [lux, luy, rdx, rdy]를 return하면 됩니다.

제한사항

• 1 ≤ wallpaper의 길이 ≤ 50
• 1 ≤ wallpaper[i]의 길이 ≤ 50
  • wallpaper의 모든 원소의 길이는 동일합니다.
• wallpaper[i][j]는 바탕화면에서 i + 1행 j + 1열에 해당하는 칸의 상태를 나타냅니다.
• wallpaper[i][j]는 "#" 또는 "."의 값만 가집니다.
• 바탕화면에는 적어도 하나의 파일이 있습니다.
• 드래그 시작점 (lux, luy)와 끝점 (rdx, rdy)는 lux < rdx, luy < rdy를 만족해야 합니다.

입출력 예

wallpaper result

풀이

해당 문제는 1차적인 생각으로는 2차원 배열로 풀이하면 됐었고, 2차적인 생각으로는 가장 큰 x,y 좌표값을 저장하는 변수와 가장 작은 x,y 좌표값을 저장하는 변수를 선언 해 마지막으로 가장 큰 x,y 좌표값에 +1를 하면 되겠다는 생각을 하게 되었다.

정답률이 35퍼센트라 겁먹고 들어갔으나 생각보다 너무 빨리 오류도 없이 쉽게 풀어서 당황..

3차적인 생각으로는 반례를 살펴보게 되었는데 파일이 하나일경우가 반례가 될까? 했지만 출력이 정답과 다르지 않아서 그냥 제출했더니 맞았다.

class Solution {
    public int[] solution(String[] wallpaper) {
        int leastX = wallpaper[0].length();
        int leastY = wallpaper.length;
        int maxX = 0;
        int maxY = 0;
        for(int i=0; i<wallpaper.length;i++){
            for(int j=0; j<wallpaper[0].length();j++){
                int nowX = j;
                int nowY = i;
                if(wallpaper[i].charAt(j)=='#'){
                    if(leastX>nowX){
                        leastX=nowX;
                    }
                    if(leastY>nowY){
                        leastY=nowY;
                    }
                    if(maxX<nowX){
                        maxX=nowX;
                    }
                    if(maxY<nowY){
                        maxY=nowY;
                    }
                }
            }
        }

        return new int[]{leastY, leastX, maxY + 1, maxX + 1};
    }
}

읽기 쉬운 코드를 작성하려고 하니 딱히 코드가 엄청 짧지 않아도 이해하기 쉽게 구현이 가능한거 같다. 실력도 늘은거 같고 뿌듯 ><

단위테스트는 어떻게 진행될까?

• 사람마다 다를 수 있으나 (?) 기본적으론 gwt (given & when & then)으로 진행된다.
  • Given ⇒ 어떠한 상황이 주어진다.
  • When ⇒ 어떠한 행동을 한다면
  • Then ⇒ 어떠한 행동이 돌아온다.
• 단순히 이렇게 기억하면 쉽다.

사용되는 라이브러리

• 보통 테스트는 비즈니스 로직 단위테스트, 컨트롤러 단위테스트, 리포지토리 단위테스트 이렇게 이뤄지는것 같다.
  • 비즈니스 로직 단위테스트에는 MockitoExtension을 사용한다.
  • 컨틀롤러 단위테스트에는 SpringBootTest 어노테이션을 달고 MockMvc 를 객체로 사용한다.
  • 리포지토리 단위테스트에는 DataJPATest 어노테이션을 달고 테스트한다.
• 단순히 하나하나가 어떠한 행동들을 지원하는지는 나중에 알아보고, 어떻게 테스트해야지 성공적인 결과를 가져올 수 있는지 일단 행동해보자.

비즈니스 로직 단위테스트

테스트 클래스 생성

단순히 테스트 폴더에 테스트 클래스를 생성한다.

spring boot starter test 디펜던시를 추가하면 자동으로 junit 라이브러리까지 사용이 가능하다.

@DisplayName("비즈니스 로직 - 게시글")
@ExtendWith(MockitoExtension.class)
class ArticleServiceTest {

테스트를 원하는 클래스에 MockitoExtension 을 상속받아주고 어떠한 테스트를 진행할 것인지 @DisplayName으로 명시해 준다.

@InjectMocks private ArticleService sut;
@Mock private ArticleRepository articleRepository;

핵심이 되는 서비스클래스를 @InjectMocks 어노테이션을 사용하여 필드변수로 선언해 준다.

sut는 System Under Test 테스트 대상 시스템을 뜻한다.

그리고 해당 서비스 클래스에 주입되어야 하는 Repository 들을 @Mock 어노테이션을 사용해 주입시켜 준다.

(주축이 되는 객체에 주입되어야 하는 객체들을 하나라도 주입시키지 않으면 오류가 발생한다.)

테스트에 사용되는 메서드

• given → 테스트가 진행되는 목업 객체가 가 어떠한 메서드를 호출할 때의 결과를 가정할 수 있다.
  • 리턴값이 있다면 목업 객체를, 예외가 발생해야 한다면 예외를 던져주는 등 상황을 지정할 수 있다.
    • 보통 테스트 대상 시스템의 비즈니스 로직 속 호출되는 메서드들에 대한 리턴값을 지정하는데 쓰인다.

• when & then → 해당 비즈니스 로직을 호출했을 시에 어떠한 결과가 나와야 하는지를 명시한다.
  • when에는 예외가 발생되어야 하는 상황이나 메서드를 호출한다.
  • then 에는 AssertJ 라이브러리를 활용해 assertThat 메서드로 검증을 진행하거나 then() 메소드로 어떠한 메서드를 호출을 했는지 확인할 수 있다.

비즈니스 로직 단위테스트 코드 작성

• 단위테스트 메서드의 네이밍은 given 주어진 것_when 어떠한 행동을 할 때_then 어떠한 것을 하거나 반납한다. 이런 느낌으로 작성해도 좋고, @DisplayName 어노테이션을 사용하여 따로 상황만 명시해줘도 된다.
• 어떠한 행동을 했을 때 대상이 되는 엔티티에 변경사항이 존재하는지, 혹은 엔티티매니저가 어떠한 행동을 실행했는지 에 대한 상황을 가정 후 테스트를 진행할 수 있다.
• 예외가 발생할 때는 Throwable 클래스의 정적 메서드인 catchThrowable()를 이용하여 람다식으로 예외를 캐치해 준다.

@Test
    @DisplayName("댓글 단건 조회시 없는 댓글을 조회하면 예외가 발생한다$")
    void givenNotExistArticleCommentId_whenGetAnArticleComment_thenThrowsException() {
        //given
        given(articleCommentRepository.findById(any())).willReturn(Optional.empty());

        //when
        Throwable throwable = catchThrowable(() -> sut.getArticleComment(1L));

        //then
        then(articleCommentRepository).should().findById(any());
        assertThat(throwable).isInstanceOf(EntityNotFoundException.class);
    }

• 이때의 생각해볼 수 있는 상황들은 무엇이 있을까? 바로 단위테스트를 진행하는 목업 객체의 역할분담이다.
  • 사실 data repository 테스트를 따로 진행한 후 비즈니스 로직 테스트는 단순히 then에 해당 비즈니스 로직이 호출되었는지 를 확인할 수 있다.
  • 하지만 위에 작성해둔 코드로 실행시켜도 문제는 없다. 단순히 해당 계층의 테스트인데 다른 계층까지 점령해도 되느냐의 차이인 것 같다.
  • 더 세분화한다면 Data Repository 테스트 / 비즈니스 로직 테스트 / MVC테스트 이렇게 세분화하여 진행할 수 있지만 결국엔 비즈니스 로직에서는 해당 비즈니스 로직을 호출할 때 모든 repository 메서드를 호출할 것이며, MVC 테스트를 진행할 때도 리퀘스트를 보내면 컨트롤러가 비즈니스 로직을 호출하게 될 것이다.
    • 이에 대한 고민을 할 필요가 있으나, 현재 상황에서는 repository 자체에 여러 커스텀 메서드 (쿼리 dsl을 활용하거나 jpql을 활용해 직접 쿼리문으로 조회하는 메서드)가 존재하지 않기 때문에 비즈니스 로직에서 데이터계층까지 테스트하는 식으로 작성했다.

예외가 발생하지 않는 정상적인 상황에서의 테스트

@Test
    @DisplayName("getArticleCommet() - 댓글 단건 조회")
    void givenArticleCommentId_whenGetAnArticleComment_thenGetsArticleComment() {
        //given
        ArticleComment articleComment = createArticleComment(createArticle(createUserAccount()),createUserAccount());
        given(articleCommentRepository.findById(any())).willReturn(Optional.of(articleComment));

        //when
        ArticleComment.ArticleCommentDto articleCommentDto = sut.getArticleComment(articleComment.getId());

        //then
        then(articleCommentRepository).should().findById(any());
        assertThat(articleCommentDto).isNotNull();
    }

• getArticleComment 메서드의 내용물로는 articleCommentRepository 가 findById로 댓글을 조회한 후 존재한다면 해당 댓글을, 존재하지 않는다면 EntityNotFoundException을 발생시키도록 되어있다.
• given으로 상황을 만들어준다. 모키토는 여러 가지 메서드를 제공해주는데, 그중 any() 는 말그대로 어떠한 상황에서든지 willReturn() 메소드의 매개값을 리턴해준다.
• when은 해당 시점을 뜻한다. 어떠한 메소드를 호출할 때 then에서 검증을 진행한다.
• then에서는 assertThat() 메서드로 어떠한 엔티티를 영속시켰을 때 해당 레포지토리에 저장된 데이터의 수가 +1 이 되었는지 , 혹은 해당 엔티티 객체의 멤버변수에 변동사항이 있는지 까지 테스트가 가능하다.

이렇게만 작성하면 성공적인 테스트 결과를 얻을 수 있다.

이렇게 여러 상황을 지정할 수 있다.

컨트롤러 단위테스트

테스트 클래스 생성

컨트롤러 테스트도 마찬가지로 새 패키지를 생성해 테스트가 진행되는 클래스의 이름뒤에 test를 붙여서 클래스를 새로 생성한다.

여기에 쓰이는 어노테이션은

• @AutoConfigureMockMvc
• @SpringBootTest
• *@Import*(*SecurityConfig*. class)

이렇게 어노테이션을 달아주면 된다.

스프링 시큐리티를 사용 중에 컨트롤러 테스트를 진행하면 시큐리티 설정도 같이 가져와야지 허튼짓을 하지 않고 테스트를 마무리 지을 수 있다.

private final MockMvc mvc;
    @MockBean
    private final SaveFileService saveFileService;
    private final ObjectMapper objectMapper;

    public SaveFileControllerTest(@Autowired MockMvc mvc, @Autowired SaveFileService saveFileService, @Autowired ObjectMapper objectMapper) {
        this.mvc = mvc;
        this.saveFileService = saveFileService;
        this.objectMapper = objectMapper;
    }

이렇게 필드변수로 MockMvc 객체를 주입해 주고, 본인의 입맛에 맞게 주입할 객체를 선언해주면 된다.

생성자에 꼭 Autowired 어노테이션을 달아주자.. 여기에 달아놓지 않으면 오류가 발생한다..

테스트에 사용되는 메서드

• given → 비즈니스 로직 테스트와 마찬가지로 뷰에서 요청이 들어왔을 때 호출되는 메서드에 대한 리턴값이나 상황을 지정해줄 수 있다.
• perform
  • get → GET 요청을 할 때 사용한다.
  • post → POST 요청을 할 때 사용한다. 위에 있는 objectMapper 객체로 dto를 json 형태로 변환해서 매개값으로 전달할 수 있다.
    • contentType → 데이터를 어떠한 타입으로 전송하는지를 명시한다.
    • cotent → 전달하는 데이터를 목업 데이터로 전송한다.
  • put → PUT 요청을 할 때 사용한다. 제공하는 메서드는 post와 같다.
  • delete → DELETE 요청을 할 때 사용한다.
    • 마찬가지로 delete 요청을 보내기 위해 전달되어야 하는 데이터들을 contentType과 content로 정의해 전달할 수 있다.
  • andExpect / andDo → 해당 요청을 보내면 어떠한 응답이 와야 하는지를 명시한다.
    • view → 어떠한 페이지로 이동이 된다든가.. 하는지를 명시한다.
    • model → 어떠한 모델이 attribute 되었는지를 명시한다.
• 해당 메서드만 적절히 잘 사용하면 모든 테스트를 실패 없이 끝낼 수 있다.

컨트롤러 테스트 코드 작성

이전에 신경 써야 하는 부분이 있다.

• 스프링 시큐리티를 적용한 프로젝트인데, 시큐리티 콘텍스트에 담긴 인증정보를 가져오는 메서드가 존재한다거나, authenticatedPrincipal 어노테이션을 사용하는 메소드가 존재할 때의 상황이다.
• 이때를 대비해 @BeforeEach 어노테이션을 사용한 메서드를 선언해 각 테스트메서드 별로 호출 전 상황을 잡아줄 수 있다.
  • 계정을 생성해 놓는다던지, 글을 등록해놓는다던지 할 수 있다.
• 상황을 잡아줬다면 @WithUserDetails 같은 @With~~ 어노테이션을 사용하여 해당 문제를 해결할 수 있다.
• 만약 커스텀 필터를 구현하여 토큰을 사용하거나 하는 상황에서는 따로 어노테이션과 그에 대한 설정 클래스를 생성해 구현할 수 있다.
  • Spring Securit Test 디펜던시를 추가해야 사용이 가능하니 꼭 추가하자.

@DisplayName("[view][GET] 게시글 페이지 ")
    @Test
    public void givenNothing_whenRequestingArticlesView_thenReturnsArticlesView() throws Exception {
        //given
        given(articleService.searchArticles(eq(null), eq(null), any(Pageable.class))).willReturn(Page.empty());
        //when & then
        mvc.perform(get("/articles")).andExpect(status().isOk())
                .andExpect(content().contentTypeCompatibleWith(MediaType.TEXT_HTML))
                .andExpect(view().name("articles/index"))
                .andExpect(model().attributeExists("articles"));
        then(articleService).should().searchArticles(eq(null), eq(null), any(Pageable.class));
    }

• 기본적인 GET 요청을 보냈을 때의 테스트코드이다.
• @DisplayName에 마찬가지로 테스트 상황을 명시한다.
  • 이때 의문점은 메서드의 이름에 given 에 해당 메소드 필드 속 given 메소드의 내용을 명시해야 하는지, 아니면 실제 상황을 명시해야 하는지를 아직 정확히 이해하지 못했다.
• perform() 메서드를 호출해 어떠한 url로 어떠한 요청을 보냈을 때, 어떠한 응답이 올 때 어떠한 것을 반환하는지를 명시해 준다.
• 본인은 then에 해당 url로 요청을 보냈을 때 어떠한 비즈니스 로직이 호출되는지를 명시해 주었다.
  • 해당 부분도 솔직히 정답은 없을 거라 본다.. 각자 프로젝트를 진행할 때 정해둔 규칙에 따라서 작성하면 될 것 같다.

@DisplayName("[view][POST] 게시글 등록 ")
    @Test
    @WithUserDetails("test")
    public void givenArticleInfo_whenSavingArticle_thenSavesArticle() throws Exception {
        //given
        Article.ArticleRequest articleRequest = Article.ArticleRequest.builder()
                .title("haha421")
                .content("haha412")
                .fileIds("")
                .build();
        Article article = createArticle(createUserAccount());
        given(saveFileService.getFileDtosFromRequestsFileIds(any())).willReturn(new HashSet<>());
        given(articleService.saveArticle(any(), any())).willReturn(Article.ArticleDto.from(article));

        //when & then
        mvc.perform(post("/articles")
                        .contentType(MediaType.APPLICATION_JSON)
                        .content(mapper.writeValueAsString(articleRequest)))
                .andExpect(status().isOk())
                .andExpect(content().contentTypeCompatibleWith(MediaType.TEXT_PLAIN));
        then(saveFileService).should().getFileDtosFromRequestsFileIds(any());
    }

• POST / PUT 요청을 보낼 때의 테스트코드이다.
• ObjectMapper 객체를 활용해 json으로 변환 후 전달 할 수 있다.
• given 에는 마찬가지로 해당 url로 요청을 보냈을 때 호출되는 비즈니스 로직 속 또 다른 메서드까지 반환값을 지정해줄 수 있다.

@DisplayName("[view][DELETE] 로그인이 되어있지 않은 상태로 게시글을 삭제하면 BAD_REQUEST를 반환한다.")
    @Test
    public void givenArticleId_whenTryingToDELETEArticle_thenReturnBadRequest() throws Exception {
        Map<String, String> articleId = Map.of("articleId", "1");
        //when&then
        mvc.perform(delete("/articles").contentType(MediaType.APPLICATION_JSON).content(mapper.writeValueAsString(articleId)))
                .andExpect(status().isBadRequest());
    }

• DELETE 요청을 보냈을 때, 예외가 발생하는 상황을 담은 테스트코드이다.

이렇게 각 REST API 별로 상황을 만들어서 테스트가 가능하다.

마무리

테스트코드 작성하는 법을 배워보진 않았지만, 어쩌다 보니 규칙을 알게 되어 제 나름대로 정리해본 글입니다.

제가 직접 실행해보았을 때의 각각의 역할은 어느 정도 알게 되었지만, 해당 메서드들의 원리는 아직 알지 못합니다.

조언해주시거나 고쳐야 할 부분이 존재한다면 댓글 꼭 달아주세요! 감사합니다.

서론

주간 목표 

• 스프링부트 프로젝트 기능 구현 ⭕️
• 알고리즘 자유롭게 공부 후 문제 풀이 ⭕️
• 이펙티브 자바 / JPA 책 스터디 ⭕️ 

본론

알고리즘 자유롭게 공부 후 문제 풀이

드디어 첫 토이프로젝트가 마무리 되고, 알고리즘 공부를 다시 시작했습니다.

이번주에 진행한 알고리즘 파트는 링크드리스트, 해시, 힙 자료구조와 우선순위 큐 입니다.

문제는 해시/힙 자료구조 위주로 풀이했으며, 링크드리스트 에 대해서 요약정리도 진행했습니다.

링크드 리스트

https://velog.io/@brince/Linked-List-%EC%A7%81%EC%A0%91-%EA%B5%AC%ED%98%84%ED%95%B4%EB%B3%B4%EA%B3%A0-%EC%9B%90%EB%A6%AC-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

링크드리스트 같은 경우에는 일단 기본적으로 배열과 큰 차이점을 갖고 있습니다.

링크드 리스트는 말그대로 연결 리스트 인데요, 각각 인덱스의 원소끼리 서로 체인으로 연결되어있어서 중간에 데이터를 삽입/삭제 시에 기존에 연결된 체인을 끊고 새로 연결한다 정도로 쉽게 이해할 수 있는데요,

기존엔 이정도로만 익혔지만 이번에 공부하면서 새로 알게된 부분은 링크드 리스트는 각각의 노드에 데이터와 포인터로 이루어져 데이터에는 데이터가 저장되고, 포인터에는 다음 데이터의 주소를 저장하는 형식으로 이루어져있다는걸 알게 되었습니다.

예를들어 3개의 노드가가 연결리스트 안에 존재한다면, 마지막 노드의 포인터는 null이고, 새로 삽입을 할때 해당 포인터에 다음 노드를 참조시키는 것으로 데이터를 삽입/삭제 합니다.

마찬가지로 링크드리스트를 직접 구현해보고 기존에는 단순히 시간이 좀 걸린다~ 정도로만 알고있었지만 자료를 넣고 빼고 하는데 좀 복잡하구나.. 를 알게되었습니다.

스프링부트 프로젝트 기능 구현

이번 한주는 개인적으로 프로젝트에 시간을 많이 투자했던 한 주 였습니다.

이번주에 진행했던 것들은 게시판 프로젝트에 계정 엔티티에 이미지 입출력을 적용해 프로필 이미지를 변경하는 기능을 구현하는것과,

그것을 응용해 단순 파일만 업로드하고 출력하는게 아닌 JPA Repository로 파일 DB저장소를 만들고 저장/삭제/조회 를 구현하고

또 그것을 응용해 게시판에 외부 에디터 / 뷰어를 적용해 이미지 입출력까지 진행후 리팩토링까지 진행해보았습니다.

마무리

• 알차게 보낸 한 주 였던것 같습니다. 알고리즘을 오랜만에 다시 공부하게 되었는데 확실히 전보다 이해가 더 잘되는 기분입니다. 꾸준히 코딩을 하는 습관을 들이는게 중요한것같다고 한번 더 느끼게 되었습니다.
• 이펙티브 자바를 공부하면서 애를 먹었습니다. 정리할정도로 그것들을 활용할 길이 적었기 때문입니다. 공부하는 내용의 대부분이 직접 지금 당장 사용할 일들이 없는 레거시 코드였습니다. 마찬가지로 앞으로는 모든 파트를 공부하기 보다는 힘든 부분은 넘기고 다음에 도움이 필요할때 참고해야겠다고 다짐하게 되었습니다.
• 이제 기본적인 스프링 프로젝트를 진행할때 크게 겪는 문제는 없는것 같은 느낌입니다. 클린코드와 리팩토링에 대해서 공부를 시작하면 좋을거같다는 생각이 들었습니다 🤔

https://codinghentai.tistory.com/2

해당 글과 이어집니다.

저번 글에서 비동기 통신으로 즉각적으로 이미지를 업로드/붙여 넣기를 하면 이미지를 서버에 업로드 후 db에 저장, 그리고 출력까지 해오는 로직을 구현했었는데요,

이제부터는 게시글과 파일의 연관관계를 디테일하게 설정해 잉여파일까지 관리할 수 있는 로직을 구현해봅니다.

게시글 등록시에 중간 관계 엔티티 영속해주기

어떠한 기능을 구현하고자 할 때 가장 1차원적으로 생각해보는 게 큰 도움이 되는 것 같습니다.

지금 프로젝트의 구조는 게시글을 등록할때 리퀘스트 dto를 전달하는 방식으로 글을 등록했기 때문에,

단순히 파일 업로드 후 리스폰스 엔티티로 객체를 반환해준다면, 게시글 등록시에 리퀘스트 dto에 반환된 객체의 id값을 같이 받아오면 되겠구나! 하고 생각했습니다.

                    success: function(data) {
                        //console.log('ajax 이미지 업로드 성공');
                        url += data.fileName;
                        fileIds += data.id + ",";
                        // callback : 에디터(마크다운 편집기)에 표시할 텍스트, 뷰어에는 imageUrl 주소에 저장된 사진으로 나옴
                        // 형식 : ![대체 텍스트](주소)
                        callback(url, '사진 대체 텍스트 입력');
                    },

이렇게 에디터의 success 부분에 받아온 객체의 id를 문자열 변수에 append 하는 형태로 구현후에 같이 전달해줍니다.

그리고 비즈니스 로직을 수정해줄 건데요, ArticleSaveFile 엔티티 클래스는 게시글과 파일의 연관관계를 위해서 생성했기 때문에 repository는 게시글과 파일의 서비스 클래스에 둘 다 주입해줄 겁니다.

그전에 SaveFile 서비스에서 비즈니스 로직을 구현해주어야 합니다. 받아온 fileIds로 file set을 반환해주는 로직을 구현합니다.

    public Set<SaveFile.SaveFileDto> getFileDtosFromRequestsFileIds(Article.ArticleRequest dto) {
        StringTokenizer st = new StringTokenizer(dto.getFileIds(), ",");
        Set<SaveFile.SaveFileDto> saveFileDtos = new HashSet<>();
        while(st.hasMoreTokens()){
            Long fileId = Long.valueOf(st.nextToken());
            log.info("fileId: {}", fileId);
            saveFileDtos.add(saveFileRepository.findById(fileId).map(SaveFile.SaveFileDto::from).orElseThrow(() -> new EntityNotFoundException("파일이 없습니다 - fileId: " + fileId)));
        }
        return saveFileDtos;
    }

이렇게 HashSet을 생성해 StringTokenizer로 잘라서 dto로 가져와서 set에 담아 반환해줍니다.

이제 게시글 컨트롤러에서 리퀘스트 Dto 에 담긴 파일 아이디로 파일 dto를 가져와 같이 비즈니스 로직으로 넘겨줍니다.

    @ResponseBody
    @PostMapping
    public ResponseEntity<String> saveArticle(@RequestBody @Valid Article.ArticleRequest dto, BindingResult bindingResult,
                                              @AuthenticationPrincipal UserAccount.BoardPrincipal boardPrincipal) {
        if (bindingResult.hasErrors()) {
            return new ResponseEntity<>(ErrorMessages.ENTITY_NOT_VALID, HttpStatus.BAD_REQUEST);
        }
        if (boardPrincipal == null) {
            return new ResponseEntity<>(ErrorMessages.ACCESS_TOKEN_NOT_FOUND, HttpStatus.BAD_REQUEST);
        }
        Set<SaveFile.SaveFileDto> saveFileDtos = saveFileService.getFileDtosFromRequestsFileIds(dto);
        saveFileService.deleteUnuploadedFilesFromArticleContent(dto.getContent(), dto.getFileIds());
        return new ResponseEntity<>(articleService.saveArticle(dto.toDto(boardPrincipal.toDto()), Hashtag.HashtagDto.from(dto.getHashtag()), saveFileDtos).id().toString(), HttpStatus.OK);
    }

    public Article.ArticleDto saveArticle(Article.ArticleDto dto, List<Hashtag.HashtagDto> hashtagDtos, Set<SaveFile.SaveFileDto> saveFileDtos) {
        Article article =articleRepository.save(dto.toEntity());
        for (Hashtag.HashtagDto hashtag : hashtagDtos) {
                Hashtag hashtag1= hashtagRepository.findByHashtag(hashtag.hashtag()).orElseGet(()-> hashtagRepository.save(hashtag.toEntity()));
                articlehashtagrepository.save(ArticleHashtag.of(article,hashtag1));
        }
        for (SaveFile.SaveFileDto saveFileDto : saveFileDtos) {
            if(dto.content().contains(saveFileDto.fileName())){
                articleSaveFileRepository.save(ArticleSaveFile.of(article, saveFileDto.toEntity()));
            }
        }
        return Article.ArticleDto.from(article);
    }

저는 해시태그도 양방향 관계를 중간 엔티티로 맺어주어서 등록하도록 했는데요, 파일도 마찬가지로 똑같은 로직으로 구현했습니다.

이렇게 구현하면 게시글에 이미지가 첨부되었을 때 중간 테이블에서 외래 키를 참조하여 데이터를 생성하게 됩니다.

하지만 게시글을 등록할 시점에 게시글 내용에 이미지가 존재하지 않는다면?(지워진 상태라면?)

위에 코드에서 각각의 파일 이름이 게시글의 내용에 포함되지 않으면 맵핑을 하지 않는 방향으로 구현할 수 있는데요,

그렇게 해버리면 단순히 파일만 업로드되고 서버상에 잔여 파일이 남고 DB에도 유령 데이터가 존재하게 됩니다.

저는 그래서 파일 엔티티를 관리하는 비즈니스 로직에 게시글의 콘텐츠와 각 파일의 이름을 비교해 삭제해버리는 로직을 구현해보았습니다.

 -> 해당 로직을 응용해서 게시글 내에 '#'를 포함해 작성한다면 해시태그를 자동으로 등록하도록 하는 로직도 구현할 수 있지 않을까? 하는 생각도 들었습니다. 🤔

    public void deleteUnuploadedFilesFromArticleContent(String content,String fileIds){
        if(Objects.isNull(content) || Objects.isNull(fileIds) || fileIds.equals("")){
            return;
        }
        for(String fileId : fileIds.split(",")){
            if(!content.contains(saveFileRepository.getReferenceById(Long.parseLong(fileId)).getFileName())){
                deleteFile(Long.parseLong(fileId));
            }
        }
    }

이렇게 파일 서비스에 비즈니스 로직을 구현해주었는데요, delete를 담당하는 로직 자체에서 서버에 남아있는 파일까지 삭제해버리기 때문에 글 내용과 파일 아이디를 전달하면 작업할 수 있도록 구현해주었습니다.

이렇게 구현해주면 글을 등록할 시에 글 내용에 이미지 파일이 존재하지 않는다면 서버에 잔여 파일도 존재하지 않게 되고 쓸데없는 데이터를 입력하지도 않게 됩니다 🥸

시연 화면

이렇게 에디터에 이미지를 붙여 넣기 해주고 삭제 후 업로드해봅니다.

이렇게 포함을 시키지 않아도 잔여 이미지가 남지 않게 됩니다. 

수정과 삭제의 경우엔 어떻게 대처를 할 수 있을까?

수정 같은 경우에는 글에 이미지가 포함되지 않았을 경우에 삭제해버리는 로직을 비슷하게 구현하면 됩니다.

다만 게시글을 등록할 때는 단순 즉각적으로 전달받은 업로드된 이미지의 id를 참조하여 삭제하면 됐지만

수정 같은 경우에는 파일 엔티티나 게시글 엔티티 자체가 각각 엔티티 자체에 서로의 엔티티를 참조하지 않고 중간 테이블이 존재하는 구조이기 때문에

수정 페이지 뷰에 기존에 게시글에 등록돼있던 fileId를 addattribute로 전달하고, 이미지를 업로드할 때마다 append 하는 방식으로 id를 받아와 마찬가지로 게시글에 포함이 안된 이미지는 삭제 후에 수정하는 방식으로 구현했습니다.

    public static String fileIdsToString(Set<SaveFile.SaveFileDto> saveFiles){
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < saveFiles.size(); i++) {
            sb.append(saveFiles.stream().toList().get(i).id()).append(",");
        }
        return  sb.toString();
    }

저는 이렇게 정적 유틸 메서드를 컨트롤러 유틸 클래스에 선언하고 호출했습니다.  

    @ResponseBody
    @PutMapping
    public ResponseEntity<?> updateArticle(
            @RequestBody @Valid Article.ArticleRequest articleRequest,
            BindingResult bindingResult,
            @AuthenticationPrincipal UserAccount.BoardPrincipal boardPrincipal) {
        try {
            if (bindingResult.hasErrors()) {
                return new ResponseEntity<>(ControllerUtil.getErrors(bindingResult), HttpStatus.BAD_REQUEST);
            }
            if (!Objects.equals(articleService.getWriterFromArticle(articleRequest.getArticleId()), boardPrincipal.username())) {
                return new ResponseEntity<>(ErrorMessages.ACCOUNT_NOT_MATCH, HttpStatus.BAD_REQUEST);
            }
            Set<SaveFile.SaveFileDto> saveFileDtos = saveFileService.getFileDtosFromRequestsFileIds(articleRequest);
            saveFileService.deleteUnuploadedFilesFromArticleContent(articleRequest.getContent(), Objects.requireNonNull(articleRequest.getFileIds()));
            articleService.updateArticle(articleRequest.getArticleId(), articleRequest, Hashtag.HashtagDto.from(articleRequest.getHashtag()), saveFileDtos);
            return new ResponseEntity<>("articleUpdating Success", HttpStatus.OK);
        }
        catch (EntityNotFoundException e){
            return new ResponseEntity<>(ErrorMessages.ENTITY_NOT_FOUND, HttpStatus.NOT_FOUND);
        }
    }

저는 이렇게 현재 등록된 이미지와 새로 등록된 이미지 id를 받아와서 내용에 포함되어있지 않으면 파일을 삭제하고 수정하는 방식으로 구현해 잔여 파일을 처리해주었습니다 💆🏻‍♂️

삭제 같은 경우에도 마찬가지로 중간 관계 엔티티에서 id를 가져온후 중간관계 엔티티를 삭제하고 파일 엔티티를 게시글 엔티티 id를 토대로 불러와 삭제를 진행하고 게시글 엔티티를 삭제하도록 구현했습니다 :D

마치며

• 해당 기능을 구현하면서 처음으로 성능에 대한 고민을 할 수 있었습니다. (반복적인 쿼리 실행을 줄이기 위해 노력했습니다.)
• 해당 기능을 구현하면서 가장 많이 했던 고민은 역시나 역할 분담이었습니다. 파일 엔티티는 어떻게 보면 지금 프로젝트상 단독으로 처리되지 못하고 참조가 되는 구조였기 때문에 고민을 하게 되었습니다.
• 이번 기능 구현도 기본적인 에디터 옵션 사용을 제외한 나머지는 제가 직접 구현하게 되었습니다. 이제는 전체적인 프로젝트의 흐름을 어느 정도 머릿속으로 그릴 수 있게 된 것 같아서 기쁩니다 :D

해당 코드는 제 토이 프로젝트에서 작성한 코드들이며 구현 글들은 프로젝트의 문서화를 위해 작성한 글들입니다. 태클은 언제나 환영합니다!

참고한 게시글 : https://velog.io/@io_/Toast-UI-Editor-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%97%85%EB%A1%9C%EB%93%9C

서론

• 제이쿼리를 이용해 게시판 프로젝트에 Toast UI 에디터 / 뷰어를 적용시킵니다.
• 이미지 파일 업로드 기능을 구현합니다. (에디터의 hooks 옵션을 통해 이미지를 비동기통신으로 업로드 하고 출력합니다.)
• JPA로 게시글과 파일 사이의 맵핑용 엔티티 클래스를 생성해 양방향 관계를 맺어줍니다.
• 게시글 등록시에 글에 첨부되지 않은 이미 서버에 업로드된 이미지 파일을 삭제하고 첨부된 이미지와 게시글을 양방향 관계로 맺어주는 로직을 구현해봅니다.
• 게시글 수정시에 글에서 지워진 이미지나 마찬가지로 서버에 업로드되었지만 첨부되지 않은 잉여 이미지파일을 삭제해주고 연결관계를 끊어주는 로직을 구현합니다.
• 게시글 삭제시에 등록되있던 이미지까지 통째로 삭제해주는 로직을 구현합니다.

본론

벨로그 글을 작성할 때 , 이미지를 등록하거나 복사 후 붙여넣기 할때 어떻게 업로드가 되고 첨부가 될까요?

제 깃허브 프로필 사진을 캡처 후 붙여 넣기를 해보겠습니다

이렇게 같은 이미지를 여러 번 붙여 넣기 해도 매번 새로 파일이 업로드되고 바로 게시글에서 조회가 가능한데요,

해당 로직의 흐름은 이런 것 같습니다..

• 게시글에 이미지를 붙여 넣기 혹은 업로드 시에 비동기 통신으로 컨트롤러로 해당 이미지를 전송
• 전송된 이미지는 서버에 저장되고, DB에 이미지의 정보 저장 후 해당 파일 이름+@ 랜덤 문자열을 반환
• 앞단은 전달받은 파일 이름으로 GET method 로 이미지 출력을 요청
• 뒷단은 이미지 파일을 바이트 배열로 전달해 작성 폼에서 바로 이미지 출력

만약 이미지를 붙여 넣기 혹은 업로드 후에 해당 글에서 다시 이미지를 삭제 후 업로드하거나, 게시글이 삭제되었거나 수정 시에도 이미지가 해당 글에서 지워진다면 남은 잉여 파일은 어떻게 처리할까?🤔

가 해당 글의 핵심이 될 것 같습니다. 🤔

게시판 프로젝트에 Toast UI 에디터/뷰어 적용시키기 💁🏻

기존에 제가 진행하던 토이 프로젝트의 글 작성과 뷰어는 단순히 textarea 태그와 타임리프의 th:text 문법을 이용해서 작성/출력을 했었는데요,

게시판에 에디터를 적용시켜보면 얼마나 깔끔해 보일까? 혹은 이것도 어떻게 보면 open api를 활용하는 것과 비슷하다고 생각하여 적용시켜보게 되었습니다.

저는 프런트를 전혀 알지 못하기 때문에 제이쿼리로 진행했습니다.

    <!-- TOAST UI Editor CDN(JS) -->
    <script src="https://uicdn.toast.com/editor/latest/toastui-editor-all.min.js"></script>
    <!-- TOAST UI Editor CDN(CSS) -->
    <link rel="stylesheet" href="https://uicdn.toast.com/editor/latest/toastui-editor.min.css" />

적용을 시킬 작성용 폼과 게시글 출력을 시킬 html 파일의 head에 저것들을 다 넣어줍니다.

    const editor = new toastui.Editor({
        el: document.querySelector('#editor1'),
        initialEditType: 'markdown',
        previewStyle: 'vertical',
        height: '500px',
        initialValue: '내용을 입력해주세요',
        events: {
            change: function () {
                console.log(editor.getMarkdown());
            }
        },
        hooks: {
            addImageBlobHook: (blob, callback) => {
                // blob : Java Script 파일 객체
                //console.log(blob);

                const formData = new FormData();
                formData.append('file', blob);

                let url = '/files/';
                $.ajax({
                    type: 'POST',
                    enctype: 'multipart/form-data',
                    url: '/files/upload',
                    data: formData,
                    dataType: 'json',
                    processData: false,
                    contentType: false,
                    cache: false,
                    timeout: 600000,
                    success: function(data) {
                        //console.log('ajax 이미지 업로드 성공');
                        url += data.fileName;
                        fileIds += data.id + ",";
                        // callback : 에디터(마크다운 편집기)에 표시할 텍스트, 뷰어에는 imageUrl 주소에 저장된 사진으로 나옴
                        // 형식 : ![대체 텍스트](주소)
                        callback(url, '사진 대체 텍스트 입력');
                    },
                    error: function(e) {
                        //console.log('ajax 이미지 업로드 실패');
                        //console.log(e.abort([statusText]));

                        callback('image_load_fail', '사진 대체 텍스트 입력');
                    }
                });
            }
        }
    });

출처 :Toast UI Editor 이미지 업로드 - io_
해당 코드는 io_님 블로그에서 긁어왔습니다.

에디터로 별다른 코드를 추가하지 않고 이미지를 업로드하거나 붙여 넣기 하면 에디터에 몇천 자+@ 의 base64형식으로 이미지 파일이 입력되는데요, 에디터 자체에 hooks 옵션이 존재합니다.

hooks 옵션은 해당 base64 형식의 이미지를 바로 처리하고 에디터에 리턴해줍니다.

    $(document).ready(function() {
        const viewer = toastui.Editor.factory({
            el: document.querySelector("#articleContent"),
            viewer: true,
            height: "500px",
            initialValue: document.getElementById("content").value,
        });
    }
    );

해당 코드는 게시글을 조회하는 뷰 script 태그에 붙여 넣으면 됩니다.

뷰어를 따로 또 적용시키는 이유는 , 에디터에서 지원하는 기능들이 단순 html 태그로는 출력이 되지 않는 경우가 있기 때문에 뷰어도 적용해주었습니다.

게시판에서 이미지를 업로드하면 불필요한 장문의 글자를 가로 채주는 기능이 구현됐으니 이제 이미지/파일을 업로드하고 받아오는 로직을 구현해야겠죠? 🤔

파일 컨트롤러 / 서비스 생성하기

연관관계 맵핑용 중간 엔티티 클래스 생성하기

기존에 File 엔티티 클래스는 작성이 되어있다는 가정하에, 게시글 엔티티와 파일 엔티티를 연결해줄 중간 엔티티 클래스를 생성해줍니다.

@Entity
@Getter
@NoArgsConstructor
public class ArticleSaveFile {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    @Setter
    @OneToOne
    private Article article;

    @Setter
    @ManyToOne
    private SaveFile saveFile;

    private ArticleSaveFile(Long id, Article article, SaveFile saveFile) {
        this.id = id;
        this.article = article;
        this.saveFile = saveFile;
    }

    public static ArticleSaveFile of (Article article, SaveFile saveFile) {
        return new ArticleSaveFile(null, article, saveFile);
    }
}

해당 맵핑은 한 게시글에 여러 개의 파일이 첨부될 수 있기 때문에, 단순 게시글 엔티티와 파일 엔티티에 연관관계를 설정해주지 않고 중간 엔티티 클래스를 생성해 맵핑을 해주었습니다.

그리고 맵핑 엔티티를 저장할 리포지토리도 따로 생성해주었는데요, 여기서 고민할 수 있는 부분은 두 가지였습니다.

• 파일 엔티티는 단순히 혼자서 업로드되고 삭제될 수 없는 것 같은데 파일 서비스가 단독적으로 동작할 수 있게 해도 될까?
  • 해당 고민은 파일 엔티티는 파일 저장소를 구현하는 프로젝트가 아닌 이상 단독으로 다뤄질 일이 없다고 생각했기 때문에 파일 CRUD가 필요한 컨트롤러에 주입해주는 것으로 타협했습니다.
    • 그러면 애초에 다른 비즈니스 로직에서 파일 리포지토리를 사용하면 되지 않나? 에 대한 고민은 지금 프로젝트는 서비스 클래스 단위로 트랜잭션이 이뤄지기 때문에 컨트롤러에서 파일 서비스로 파일을 다룰 수 있도록 역할을 분담해주었습니다.
• 이런 중간 엔티티용 서비스와 컨트롤러도 만들어서 역할을 분리해야 할까?
  • 연관관계 맵핑 엔티티는 마찬가지로 각각의 엔티티가 존재하지 않으면 존재할 이유도 없기 때문에, 각각 비즈니스 로직에 리포지토리를 주입해 사용하도록 했습니다.

파일 엔티티 비즈니스 로직 설계하기

파일을 등록/조회/삭제 처리를 해줄 비즈니스 로직을 설계해줍니다.

@Slf4j
@RequiredArgsConstructor
@Transactional
@Service
public class SaveFileService {
    private final SaveFileRepository saveFileRepository;
    private final ArticleSaveFileRepository articleSaveFileRepository;

    @Transactional(readOnly = true)
    public SaveFile.SaveFileDto getFile(Long fileId) {
        log.info("getFile() fileId: {}", fileId);
        return saveFileRepository.findById(fileId).map(SaveFile.SaveFileDto::from).orElseThrow(()-> new EntityNotFoundException("파일이 없습니다 - fileId: " + fileId));
    }
    
    @Transactional(readOnly = true)
    public SaveFile.SaveFileDto getFileByFileName(String fileName) {
        log.info("getFile() fileId: {}", fileName);
        return saveFileRepository.findByFileName(fileName).toDto();
    }

    public void deleteFile(Long fileId) {
        log.info("deleteFile() fileId: {}", fileId);
        File file = new File(saveFileRepository.getReferenceById(fileId).getFilePath());
        if (file.exists()) {
            if(file.delete()){
                log.info("파일삭제 성공");
            }
        }
        articleSaveFileRepository.deleteBySaveFileId(fileId);
        saveFileRepository.deleteById(fileId);
    }

    public SaveFile.SaveFileDto saveFile(SaveFile.SaveFileDto saveFile) {
        log.info("saveFile() saveFile: {}", saveFile);
        return SaveFile.SaveFileDto.from(saveFileRepository.save(saveFile.toEntity()));
    }

일단 해당 파일들을 저장/삭제/조회하는 로직만 구현해주었는데요, 파일 업로드 시에 db가 아닌 서버에 저장되는 로직은 유틸 클래스를 생성해서 정적 메서드로 처리하도록 했습니다.

    public static File getMultipartFileToFile(MultipartFile multipartFile) throws IOException {
        File file = new File(uploadPath,getFileNameWithUUID(multipartFile.getOriginalFilename()));
        multipartFile.transferTo(file);
        return file;
    }

이렇게 해당 메서드를 선언하여 서버에 저장하고, 또 따로 File 타입을 (해당 File타입은 엔티티가 아닙니다) File엔티티 dto 로 변환해주는 메소드를 선언해 편의성을 챙겼습니다.

여기서 신경 쓸건 파일이 생성되지 않거나 제대로 된 파일을 전달받지 못해서 비어있는 파일 정보를 가지고 db에 저장하는 걸 방지하기 위해 해당 메서드들은 파일 컨트롤러에서 호출하도록 구현했습니다.

파일 컨트롤러 생성하기

비즈니스 로직을 구현해주었으니 이제 앞단에서 전달받은 파일을 어떻게 처리할지를 컨트롤러에서 구현해줍니다.

@RestController
@Slf4j
@RequiredArgsConstructor
public class SaveFileController {
    private final SaveFileService saveFileService;

    @PostMapping("/files")
    public ResponseEntity<?> uploadFile(@RequestPart("file")MultipartFile file, @AuthenticationPrincipal UserAccount.BoardPrincipal principal) throws IOException {
        try{
        SaveFile.SaveFileDto fileDto = saveFileService.saveFile(FileUtil.getFileDtoFromMultiPartFile(file,principal!=null ? principal.getUsername() : "anonymous"));
        return new ResponseEntity<>(fileDto, HttpStatus.OK);
        }catch (Exception e){
            log.error("uploadFile() error: {}", e.getMessage());
            return new ResponseEntity<>(ErrorMessages.FILE_UPLOAD_FAIL, HttpStatus.INTERNAL_SERVER_ERROR);
        }
    }

    @GetMapping("/files/{fileName}")
    public ResponseEntity<?> getFile(@PathVariable String fileName) throws IOException {
        try{
        File file = FileUtil.getFileFromSaveFile(saveFileService.getFileByFileName(fileName));
        byte[] imgArray = IOUtils.toByteArray(new FileInputStream(file));
        return new ResponseEntity<>(imgArray,HttpStatus.OK);
    }
        catch (EntityNotFoundException e){
            return new ResponseEntity<>(ErrorMessages.NOT_FOUND,HttpStatus.NOT_FOUND);
        }
    }
}

파일이 비어있다면(그럴리는 없지만) IOException 이 발생할 것이기 때문에 해당 예외 처리를 컨트롤러에서 진행해줍니다.

하지만 이미지가 없다고 출력이 안되면 안 되기 때문에 catch 문으로 에러 메시지를 반환해줍니다.

이미지 업로드 후 db 반영 결과 조회하기

이제 이미지를 업로드/붙여 넣기 를 하면 즉시 작성 폼에는 이미지 출력용 url과 대체 텍스트가 입력됩니다.

이렇게 이미지를 붙여넣기 하면 그 즉시 POST 메서드로 비동기 통신을 하게 되는데요 , 

이렇게 바로 DB에 반영이 됩니다.

이제 여기서 파일 컨트롤러와 게시글 컨트롤러는 분리되어있는데 게시글 서비스 클래스에서 연관관계를 맺을 수 있을까?

에 대한 로직 구현이 필요합니다.

해당 내용은 글이 길어졌기 때문에 다음 글에서 설명하도록 하겠습니다 :)