[Spring Boot][Total-Back-Office Project] Log Back을 이용한 Discord에 Exception 정보 보내기 및 Data Base 저장 feat.MyBatis & Test Code(JUnit 5) - ③ 로그 및 요청 이용자, 요청 정보 데이터 베이스에 저장

 

 

 

 

 

스프링 부트 3 백엔드 개발자 되기 : 자바 편

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

 

 

🗂 목차

🧑‍💻 코딩

✅  [Spring Boot][Total-Back-Office Project] AOP, Annotation을 이용한 API 동작 시간 측정
✅ [Spring Boot][Total-Back-Office Project] AOP, Annotation을 이용한 API 요청 이용자 정보 가져오기 feat.MyBatis & Test Code(JUnit 5) (https://junyharang.tistory.com/457)
✅ [Spring Boot][Total-Back-Office Project] Log Back을 이용한 Discord에 Exception 정보 보내기 및 Data Base  저장 feat.MyBatis & Test Code(JUnit 5) - ① Log Back 설정
✅ [Spring Boot][Total-Back-Office Project] Log Back을 이용한 Discord에 Exception 정보 보내기 및 Data Base 저장 feat.MyBatis & Test Code(JUnit 5) - ② 디스코드로 로그 정보 발송
✅ [Spring Boot][Total-Back-Office Project] Log Back을 이용한 Discord에 Exception 정보 보내기 및 Data Base 저장 feat.MyBatis & Test Code(JUnit 5) - ③ 로그 및 요청 이용자, 요청 정보 데이터 베이스에 저장

 

🚚 배포

⚠️ 아래 목차 중 몇몇개의 링크가 걸리지 않는 문제로 글 맨 하단에 다음 글로 이동할 수 있게 해 두었습니다.

✅ [CI/CD] Jenkins와 Gitea 연동
✅ [CI/CD] Jenkins Trigger 정보 Discord로 보내기
✅ [CI/CD] 정적 코드 분석 툴 SonarQube와 Jenkins 연동
✅ [CI/CD] SonarQube를 통해 Code Convention 적용
✅ [DevOps] JAVA Gradle JaCoCo (Code coverage) 설정하기 
✅ [DevOps] JAVA Gradle JaCoCo (Code coverage) 설정하기 (추가)(https://junyharang.tistory.com/392)
✅ [CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ① Application Linuxt(Ubuntu)에 SSH를 이용한 파일 전송
✅ [CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ② Create Docker Image And BackUp
✅ [CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ③ Application Server Docker Job (① Application 도커 존재 여부 확인)
✅ [CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ③ Application Server Docker Job (② Application Docker Run)(https://junyharang.tistory.com/406)
✅ [CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ③ Application Server Docker Job (③ Application Docker Health Check)
✅ [CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ④ NGINX Server Docker Job (① NGINX 각 종 설정) 
✅ [CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ④ NGINX Server Docker Job (② NGINX Docker 존재 여부 확인) 
✅ [CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ④ NGINX Server Docker Job (③ NGINX Docker Run & Health Check)
✅ [CI/CD] Jenkins + Docker를 이용한 무중단 배포 - ④ NGINX Server Docker Job (③ NGINX 재 설정)

 

💾 Git Hub Repository : https://github.com/junyharang-personal-project/junyss-total-back-office

GitHub - junyharang-personal-project/junyss-total-back-office: [Back-Office] 디스코드 봇과 Logback, AOP 등을 이용하

 

 

 

 

🚀 로그 및 요청 이용자, 요청 정보 데이터 베이스에 저장

    🔽 개요

        📦 소개

지난 글에서 주니는 Exception 정보 및 요청 이용자, 요청 정보를 디스코드에 전달하는 것에 대해 구현해 보았어요.

이번 글에서는 Exception 정보 및 요청 이용자, 요청 정보를 데이터 베이스에 저장하는 것에 대해 구현해 보려고 해요.

해당 기능을 구현하기 위해 많이 찾아 보았는데, 원래 Logback에서 데이터 베이스로 바로 로그 정보를 저장할 수 있게 해 주는 기능이 있었는데, 보안 상의 이유로 더는 사용할 수 없다는 것을 찾게 되었어요.

Logback-classic 1.2.8 DBAppender Missing

여러 방법을 고민해보다가 주니는 직접 구현하는 것으로 생각하고, 작업을 진행해 보았습니다.

 

 

    🔽 소스 코드 분석

        📦 DataBaseAppender.java

DataBaseAppender 14 ~ 40번째 줄

위 클래스는 Data Base에 Log 저장을 위한 Appender를 만들어 준 부분이에요.

해당 클래스는 DiscordAppender 클래스에서 호출되게 되는데, 이 부분은 이 전 글에서 상세하게 확인하실 수 있어요.

[Spring Boot][Total-Back-Office Project] Log Back을 이용한 Discord에 Exception 정보 보내기 및 Data Base 저장 feat.M

 

해당 메소드는 매개 변수로 로그 레벨과 Exception 간략 내용, Exception 상세 내용 그리고, 서버 정보, Exception 발생 시 발생 이용자의 정보를 담은 Map을 매개 변수로 전달 받게 해 주었어요.

최초 31번째 줄에서 위의 모든 내용을 담을 수 있는 DTO 객체를 선언 및 초기화해 주었어요.

TotalErrorRecordSaveRequestDto

위와 같이 해당 DTO는 Exception 발생 일시와 로그 레벨, 서버 정보, 이용자 정보와 요청 정보 그리고, Exception 내용 등을 담을 수 있는 객체에요.

DataBaseAppender 14 ~ 40번째 줄

728x90

그런 뒤 해당 DTO에 각각의 내용들을 담아 주었어요.

DataBaseAppender 42 ~ 71번째 줄

이용자 정보와 요청 정보가 담긴 mdcPropertyMap을 Key와 Value로 나누어 반복문을 수행해 주었어요.
이를 통해 43 ~ 44번째 줄에 각각의 Key와 Value 정보를 담아 줍니다.

그런 뒤 분기문을 통해 key가 무엇인지를 확인하고, tottalErrorRecordSaveRequestDTO 객체에 Setter를 통해 각각의 값이 알맞게 들어갈 수 있도록 처리 해 주었어요.

60 ~ 66번째 줄은 에러 간략 내용과 에러 상세 내용이 담겼는지를 확인하고, 담겨 있다면 객체에 담을 수 있도록 분기 처리를 해 준 부분이에요.

이렇게 반복문을 모두 돌고, 69번째 줄을 통해 각각의 값이 객체에 알맞게 담기면 본격적으로 데이터 베이스 저장을 위한 여정이 시작됩니다.

 

 

 

        📦 BackOfficeAPICaller.logSaveAPICall()

BackOfficeAPICaller.logSaveApiCall()

최초 위 메소드 280번째 줄을 보면 APIUriInfo.LOG 기반으로 StringBuilder 객체인 suffixURL 변수를 초기화 해 주었어요. APIUriInfo.Log는 API 호출 시 사용되는 URL의 일부를 나타내는데,

APIUrlInfo.java

31번째 줄에 LOG 상수 변수에 선언된 문자열 값을 가져와 데이터 베이스 저장 처리를 위한 API 호출을 준비해 준 부분이에요.

281번째 줄을 통해 ApiCallUtil 클래스의 callDiscordBotPostAPI()를 호출하여 HTTP Method Post를 이용하여 API를 호출해 주었어요. 이 때, 호출 대상 URL과 저장할 값을 담은 객체를 함께 매개 변수로 전달해 주었어요.

 

 

        📦 APICallUtil.callDiscordBotPostAPI()

APICallUtil.callDiscordBotPostAPI() 67 ~ 98번째 줄

반응형

위 메소드는 본격적으로 API를 호출하는 부분이에요.
해당 메소드는 suffixUrl과 object를 매개 변수로 받고, 해당 URL로 obecjt 변수를 JSON 형태로 변환하여 POST 요청으로 전송하는 부분이에요.

최초 76번째 줄은 기본 API 호출 URL의 prefix 값을 가져오도록 해 주었어요.

Environment.initPrefixAPIURL()

여기서 URL의 prefix를 정의해 주는데, 39번째 줄을 통해 현재 구동중인 구동 환경 (local, dev, prod) 정보를 가져오게 해 준 뒤 해당 구동 환경이 어떤 것이냐의 따라 URL을 다르게 정의하도록 처리해 주었어요.

그런 뒤 49번째 줄에 initCommonAPIURL()을 호출해 줍니다.

Environment.initCommonAPIURL()

해당 메소드는 URL에 공통적으로 들어가야 하는 내용을 첨가하기 위한 역할을 해 주고 있어요.

APIUriInfo

바로 위와 같이 구동 Port 번호를 다르게 하여 URL을 설정할 수 있도록 처리해 주었어요.

이렇게 하면 구동 환경에 따른 기본 호출하고자 하는 URL을 만들어 주게 됩니다.

APICallUtil.callDiscordBotPostAPI() 67 ~ 98번째 줄

다시 이 부분을 보면 77번째 줄에 suffixUrl을 defaultApiCallUrlInfo에 추가하여 완전한 API 호출 URL을 구성해 주었어요.

defaultApiCallUrl은 URL 객체로 데이터 베이스 저장을 위한 API의 엔드포인트 URL를 나타내요.

78번째 줄은 JSON 형식의 데이터와 Java 객체 사이의 변환을 담당하는 Jackson Library의 ObjectMapper 객체를 생성해 준 것이에요.

79번째 줄은 POST 요청으로 보낼 JSON 형태의 데이터를 담을 문자열 변수를 초기화 해 준 부분이에요.

81번째 줄에 매개변수로 전달된 object 객체 즉, DTO 객체를 JSON 형식으로 바꾸기 전에 DTO 객체가 제대로 들어왔는지 확인하기 위한 부분이에요.

제대로 들어왔다면 해당 객체를 JSON 형태로 변환하여 requestBodyJsonData에 저장해 주는 부분이에요.
이를 위해 objectMapper.writeValueAsString()을 이용하여 object 객체를 JSON 문자열로 변환해 줍니다.

85번째 줄은 defaultApiCallUrl로 부터 HttpURLConnection을 열어 API 호출에 사용할 연결 (connection)을 생성해 주는 부분이에요.

그런 뒤 86 ~ 90번째 내용은 아래와 같아요.

∙ connection.setRequestMethod("POST"): HTTP 요청 방식을 POST로 설정.
∙ connection.setConnectTimeout(5000): 연결 타임아웃을 5000ms(5초)로 설정.
∙ connection.setRequestProperty("Content-Type", "application/json"): POST 요청의 Content-Type을
    Application/json으로 설정. 이는 요청 본문이 JSON 형식임을 나타내기 위함.
∙ connection.setRequestProperty("Accept", "application/json"): Server로 부터 받을 Data의 Content-Type을 
   application/json으로 설정. 이는 Server에게 JSON 형식으로 응답을 보내달라고 요청하는 부분.
∙ connection.setDoOutPut(true): 출력 스트림을 사용하여 요청 본문을 전송할 것임을 나타냄.

92번째 줄은 connection.getOutputStream()을 호출하여 출력 스트림을 가져오게 해 주는 부분이에요.
93 ~ 94번째 줄은 requestBodyJsonData 변수의 문자열을 Byte Array(바이트 배열)로 변환하여 출력 스트림에 기록해 주는 부분이에요.
그런 뒤 95번째 줄을 통해 출력 스트림을 닫아 줍니다.

만약 IO Exception이 발생하면 주니가 만든 커스텀 APICallException 예외를 던지게 처리해 주었어요.

이렇게 구현된 callPostApi()는 데이터 베이스에 해당 내용을 저장하기 위한 API를 사용하여 JSON 데이터를 POST 방식으로 전송하는 작업을 수행하고 있어요. 이를 통해 데이터 베이스에 JSON 형태에 데이터를 전송하여 내용을 기록하고, 처리하는데 사용된답니다. 만약 전송 중 IO Exception이 터지게 되면 이 예외는 APICallException으로 던져지며, 이를 상위 코드에서 적절히 처리할 수 있도록 해 주었어요.

 

APICallUtil.callDiscordBotPostAPI() 100 ~ 114번째 줄

위 내용은 HTTP 요청 뒤 응답을 처리하는 부분이에요.
API 호출의 응답이 HTTP 상태 코드 201(Created)인 경우에만 Logic을 처리하도록 해 주었어요.

이 경우에는 HTTP 요청이 성공적으로 완료되어 데이터 베이스에 로그 등이 저장된 것이에요.

만약 성공하지 못하면? 빈 JSONObject를 생성하게 해 주었어요.

좀 더 자세히 코드를 살펴보면 100번째 줄은 connection.getResponseCode()를 사용하여 HTTP 응답 상태 코드를 가져오게 해 주고, 이 값이 201인 경우에만 이 블록의 코드를 실행하게 해 주었어요.
이는 HTTP 요청이 성공적으로 처리되어 데이터 베이스의 정상적으로 저장되었다는 것을 의미해요.

try (BufferedReader bufferedReader = new BufferedReader(new InputStreamReader(connection.getInputStream()))) { ... } catch (IOException ioException) { ... }

위 내용에서 connection.getInputStream()을 사용하여 응답 데이터를 읽기 위한 InputStream을 가져와 주었어요.

그런 뒤 BufferedReader.readLine()을 통해 해당 값이 Null이 아닌 경우에만 응답 데이터를 한 줄씩 읽어오도록 해 주었어요.
읽은 데이터는 104번째에 선언한 line변수에 저장해 줍니다. 데이터를 모두 읽을 때까지 계속 반복하며, 각 줄의 데이터를 line 변수에 저장해 줍니다.

107번째 줄은 응답 데이터를 JSON 형식으로 파싱하여 jsonObject에 저장해 주는 부분이에요. line 변수에 있는 데이터는 JSON 형식이기 때문에 JSONObject의 생성자를 사용하여 파싱하게 해 주었어요.
이렇게 하면 jsonObject에 최종적으로 JSON 형태의 데이터가 담기게 될 거에요. 따라서 이후에 해당 객체를 처리하여 데이터 베이스 저장 API 응답 데이터를 활용할 수 있게 해 주었어요.

109 ~ 111번째 줄은 JSON 데이터를 파싱하는 과정에서 IO Exception이 발생하면 해당 예외 처리를 위한 부분인데, 이 경우 log.error()를 통해 오류 메시지를 로그로 남길 수 있도록 해 주었어요.

마지막 113번째 줄은 상태 코드가 201이 아닌 경우 또는 응답 데이터를 읽는 과정에서 오류가 발생한 경우 빈 JSONObject를 생성하게 해 주었어요. 이것은 데이터 베이스 저장 API 응답 데이터를 처리하지 못하거나, HTTP 요청이 실패했을 경우에 해당할 것이에요.

정리해 보면 데이터 베이스 저장 API 응답을 처리하여 데이터 베이스 저장 API로부터 받은 데이터를 jsonObject로 파싱하고, HTTP 상태 코드가 201인 경우에만 해당 작업이 수행될 수 있도록 처리해 주었고, 해당 데이터는 이 후 데이터 베이스 저장 API 응답을 활용하는 용도로 사용해 준 부분이에요.

하지만, HTTP 상태 코드가 201이 아니거나, 데이터를 읽는 과정에서 오류가 발생하면 빈 JSONObject가 생성되어 데이터 베이스 저장 API의 응답 데이터를 처리하지 못하는 상태가 되도록 해 준 부분이에요.

 

 

 

    🔽 데이터 베이스 저장 API 코드 분석

        📦 ErrorRecordManagementController.java

ErrorRecordManagementController.logSave()

위 부분이 데이터 베이스의 로그 정보를 저장하는 API 부분이에요.

@ExcutionTimeCheck는 주니가 만든 커스텀 어노테이션으로 이 내용은 이 곳에서 확인 하실 수 있어요.

[Spring Boot][Total-Back-Office Project] AOP, Annotation을 이용한 API 동작 시간 측정

 

위 메소드는 TottalErrorRecordSaveRequestDto 객체를 매개 변수로 받고, 유효성 검사를 통과한 뒤 errorRecordService의 save()를 호출하여 로그를 저장하고, 그 결과를 DefaultResponse 형식으로 반환하도록 만들어준 부분이에요.

        📦 ErrorRecordServiceImpl.java

ErrorRecordServiceImpl 58 ~ 62번째 줄

위 서비스 구현체는 서버 정보를 데이터 베이스에 저장할 DAO, 로그 발생 등에 일시 등을 저장할 DAO, 이용자 정보 DAO, Error Log 정보를 데이터 베이스에 저장할 DAO를 멤버 변수로 지정해 주었고, final 키워드를 통해 @RequiredArgsConstructor를 이용하여 주입하여 주었어요.

 

ErrorRecordServiceImpl 71 ~ 111번째 줄

최초 81번째 줄에 checkNotNull()을 호출하여 TottalErrorRecordSaveRequestDto 객체가 Null인지를 확인해 주었어요.
만약 Null이라면 주니가 만든 커스텀 ErrorRecordException이 터지도록 해 주었어요.

ErrorRecordServiceImpl.checkNotNull()

87번째 줄을 통해 매개 변수로 전달된 TottalErrorRecordSaveRequestDto 객체에 들어있는 일자와 시간값을 나누기 위해 dateTimeSplit()을 호출해 줍니다.

StringUtil.dateTimeSplit()

위 메소드를 보면 TottalErrorRecordSaveRequestDTO 객체에 CreatedAt()을 통해 Log 발생 일시를 가져오는데, 공백을 기준으로 나누어 splitCreateDateTime 문자열 배열에 담아 주고 있어요.

그런 뒤 다시 TottalErrorRecordSaveRequestDto에 setter를 이용해서 0번 배열에 값은 Date 변수에 1번 배열의 값은 Time 변수에 담아지도록 해 주었어요.

이제 89번째 부터 96번째까지 각각의 메소드를 호출해서 서버 정보, 로그 발생 일시 정보, 요청 이용자 정보, 이용자 요청 정보, Error Log 정보를 각각 저장할 수 있도록 해 주었어요.

위 내용 중 Error Log 저장을 제외한 모든 내용은 이 전에 작성한 [Spring Boot][Total-Back-Office Project] AOP, Annotation을 이용한 API 요청 이용자 정보 가져오기 feat.MyBatis & Test Code(JUnit 5) 이 곳에 ConnectedUserInfoService.java 부분에서 상세히 내용을 정리해 두었어요.

[Spring Boot][Total-Back-Office Project] AOP, Annotation을 이용한 API 요청 이용자 정보 가져오기 feat.MyBatis & Te

 

그리고, 98번째 줄을 통해 errorLogProcessNullCheck()를 호출하여 각각의 메소드를 통해 반환된 PK 값이 비어있는지 확인하고, 비어 있지 않다면 resultMap에 담아 반환될 수 있도록 처리해 주었어요.

ErrorRecordServiceImpl.errorLogProcessNullCheck()

이렇게 Null인지를 확인하고, 하나라도 Null이라면 false를 반환하고, 모두 Null이 아니라면 true를 반환해 줍니다.

ErrorRecordServiceImpl.processErrorLogInfoSave()

그럼 이번에 Error Log를 데이터 베이스에 저장하는 부분에 대해 살펴 볼게요.

최초 위 메소드는 TotalErrorRecordSaveRequestDto 객체와 이 전에 데이터 베이스 저장 처리가 되어 반환된 PK 값 (내부 서버 정보, Log 발생 일시 정보, 요청 이용자 정보, 이용자 요청 정보)들을 매개 변수로 받게 되요.

그런 뒤 341번째 줄 ~ 355번째 줄까지 매개 변수가 Null인지 확인하고, Null이라면 각각의 주니가 만든 커스텀 Exception이 터질 수 있도록 처리해 주었어요.

Null이 아니라면 본격적으로 데이터 베이스 저장 여정이 시작되요.

358번째 줄에 errorRecordManagementDao.findByErrorLogLevel()을 호출하여 TotalErrorRecordSaveRequestDto에 담긴 Error Level을 통해 해당 Log에 해당하는 Log Level이 데이터 베이스에 저장되어 있는지 확인해 주었어요.

ErrorRecordManagementDaoImpl.findByErrorLogLevel()

 

ErrorRecordManagementMapper.findByErrorLogLevel()

위와 같이 log_level Table에서 level을 검색하는데, 이 때 Log Level ID만 조회되게 하여 Long Type으로 반환되게 해 주었어요.

ErrorRecordServiceImpl.processErrorLogInfoSave()

다시 이 곳으로 돌아와서 361번째 줄에 해당 ID가 Null이면 데이터 베이스에 미리 저장해논 Error Log 정보가 없다는 것이고, 이는 이상한 값이 들어왔다고 판단되어 주니가 만든 Exception이 터지도록 해 주었어요.

schema.sql log_level Table 정보

 

data.sql

위와 같이 Error Log Level로 들어올 수 있는 값을 미리 데이터 베이스에 넣어줬기 때문에 이 값이 아니라면 Exception이 터지는 것이에요.

ErrorRecordServiceImpl.processErrorLogInfoSave()

이제 위에 코드를 통해 Dao의 save()를 호출하여 데이터 베이스에 저장하게 해 주는데, 이 때, 요청 DTO에 builder()를 이용하여 내부 서버 정보의 PK, 로그 발생 일시의 PK, 요청 이용자 정보의 ID, 이용자 요청 정보의 ID, Log Level, Exception 간략 내용, Exception 상세 내용을 저장하고, 이를 VO로 Mapping하기 위해 toVO()를 호출하여 Mapping한 뒤 전달해 주었어요. 

ErrorRecordManagementDaoImpl.save()

 

ErrorRecordManagementMapper.save()

ErrorRecordManagementMapper.xml

위와 같이 SQL 문이 작성되도록 해 주었는데, log Table에 외부키로 LOG, 내부 서버 정보, 생성 일시, 요청 이용자 정보, 이용자 요청 정보, Log Level 정보를 담은 테이블과 각각 관계를 맺고, 해당 PK 값들을 저장하게 해 주었고, Exception 간략 정보와 Exception 상세 정보가 저장되도록 해 주었어요.

 

 

 

    🔽 확인

        📦 테스트

그럼 데이터 베이스에 잘 저장되는지 확인해 볼게요.

select * from server_info;

select * from data_created_date_time;

 

select * from connected_user;

 

select * from connected_user_request_info;

 

select * from log_level;

 

select * from log;

 

select * from log;

위와 같이 Exception 이 터지면 주니가 저장하고자 했던 모든 정보가 잘 데이터 베이스에 저장되는 걸 확인할 수 있어요.

이렇게 데이터 베이스에 저장했다면 View를 구현하여 확인할 수도 있을 것인데, 주니는 디스코드 봇을 통해 확인할 수 있도록 처리를 해 주었어요.

위의 구현 코드와는 다르지만, 디스코드 봇을 만들었던 내용을 참고하시면 해당 내용을 구현해 보실 수 있고, 주니가 작성한 코드를 이해하실 수 있을거에요.

[Spring Boot] Discord Bot(디스코드 봇) 만들기

 

 

 

        📦 테스트 코드

해당 테스트 코드 역시 이 전에 작성한 글 [Spring Boot][Total-Back-Office Project] AOP, Annotation을 이용한 API 요청 이용자 정보 가져오기 feat.MyBatis & Test Code(JUnit 5)와 큰 차이가 없고, 추가된 부분은 Controller Test 부 이기 때문에 이 부분에 대해 정리해 볼게요.

ErrorRecordManagementControllerTest 77 ~ 103번째 줄

위 테스트 코드는 @WebMvcTest를 사용하여 ErrorRecordManagementController 클래스를 테스트하며, Mockito를 사용하여 ErrorRecordService를 Mock으로 대체해 준 부분이에요.

77번째 줄은 테스트 메소드 실행순서를 MethodOrderer.OrderAnnotaion 기준으로 정렬하기 위해 사용해 준 부분이에요. 즉, @Order를 사용하여 테스트 순서를 지정해 줄 수 있어요.

78번째 줄은 Mockito 사용하기 위한 확장 클래스 MockitoExtension을 사용하여 테스트 클래스를 확장해 준 부분이에요.

79번째 줄은 ErrorRecordManagementController 클래스를 테스트하기 위한 @WebMvcTest를 선언해 준 부분이에요.
이 어노테이션은 웹 계층 테스트를 위해 필요한 Bean(빈)들만 Load(로드)하여 컨트롤러 테스트를 수행하기 위해 사용해준 것이에요.

82 ~ 83번째 줄은 MockMvc 객체를 주입 받는 부분인데, 이 객체를 사용하여 컨트롤러 테스트를 수행할 수 있기 때문에 주입 받아 주었어요.

85 ~ 86번째 줄은 ErrorRecordService의 Mock 객체를 주입 받아 주는 부분이에요.
이는 ErrorRecordService의 실제 구현을 대체하여 컨트롤러 테스트에서 목적에 맞는 동작을 정의하기 위한 용도에요.

그리고, 88 ~ 103번째 줄까지의 멤버(필드) 변수는 해당 테스트를 통해 필요한 변수들을 선언해 준 부분이에요.

이 테스트 클래스는 웹 계층을 테스트하기 위해 작성한 부분이고, 테스트 클래스에서 주입된 MockMvc 객체를 사용하여 ErrorRecordManagementController 클래스의 메소드를 호출하고, 예상되는 응답 결과와 비교하여 컨트롤러 동작을 검증하기 위한 테스트 코드에요.

ErrorRecordManagementControllerTest 156 ~ 178번째 줄

위의 테스트 메소드가 바로 Log 저장을 테스트 하기 위한 컨트롤러 테스트 메소드에요.

여기서 @Test는 해당 메소드가 테스트 메소드임을 나타내는 부분이고, @Order(0)은 테스트 메소드 실행 순서를 지정해 준 부분으로 순서를 0번째로 지정해 준 부분이에요.

@DisplayName()은 해당 테스트 메소드의 테스트 출력 시의 이름을 지정해 준 부분이에요.

최초 161 ~ 166번째까지 테스트에서 사용할 예상 결과를 담을 resultMap을 선언하고, 각각의 값을 담아 주었어요.

168 ~ 169번째 줄은 errorRecordService.save()를 Mock 객체로 대체하여, 해당 메소드가 호출될 때 주어진 값을 반환하도록 지정해 준 부분이에요.
given(...).willReturn(...)을 사용하여 메소드 호출 결과를 지정해 주었어요.

172번째 줄 MockMvc.perform(...) 부분은 mockMvc 객체를 사용하여 LogSave()를 호출하여 테스트를 수행해 줍니다.
이 때, post 메소드를 사용하여 HTTP POST 요청을 보내게 되고, contentType(MediaType.APPLICATION_JSON)을 사용하여 요청의 Content-Type을 JSON 형식으로 지정해 주었어요.
content(...)는 요청 본문을 설정하는 곳으로 initalizedMockModels()를 호출하여 테스트 데이터를 JSON 형식으로 변환하여 요청 본문에 추가해 주기 위해 사용한 부분이에요.

ErrorRecordManagementControllerTest.initializedMockModles()

위 메소드를 통해 Mock TotalErrorRecordSaveRequestDto 객체를 만들 수 있도록 처리해 주었어요.

ErrorRecordManagementControllerTest 156 ~ 178번째 줄

다시 이 곳을 보면 174번째 줄에 .andDo(print())는 테스트 수행 과정에서 요청과 응답에 대한 정보를 콘솔에 출력되도록 해 준 부분이에요. 이는 디버깅 목적으로 사용한답니다.

175 ~ 177번째 줄은 예상되는 응답을 검증하는 부분인데, 175번째 줄은 HTTP 응답 상태 코드가 200(OK)인지 검증하는 부분이고, 176번째 줄은 JSON 응답 본문에서 statusCode 필드 값이 CREATE.getStatusCode()와 일치하는지 검증하는 부분이에요.

177번째 줄은 JSON 응답 본문에서 message 필드 값이 CREATE.getMessage()와 일치하는지 검증하는 부분이에요.

위 테스트 메소드는 logSave()가 주어진 테스트 데이터로 정상적으로 호출되는지 확인하는 메소드에요.
그리고, 응답 결과가 예상한대로 반환되는지 확인하고 있어요. errorRecordService.save()는 Mock 객체로 대체 되었기 때문에 실제 데이터 베이스에 저장되는 동작은 수행하지 않아요. 대신 given(...).willReturn(...)을 사용해서 테스트 시에 반환할 예상 결과를 지정해 주고, 이를 통해 확인하게 된답니다.

이렇게 하면 테스트를 격리 시켜 실제 서비스와 데이터 베이스에 영향을 주지 않고, 로직의 동작을 확인할 수 있어요.

 

스프링 부트 3 백엔드 개발자 되기 : 자바 편

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."