TIL_040

//createdAt 은 시간차가 있으므로 비교보다는 생성됐는지 '확인'
//assertNotNull(responseDto.getCreatedAt());

 

이걸 넣고 싶었는데 잘못됐다고 오류가 난다

requestDto 로 받은 것을 반영한 후, responseDto가 todo 에서 받아 와서 createdAt 을 담게 되는데 왜 안되는지 모르겠다

---

AOP 적용 방법을 잘 모르겠다

Controller 에 적용하려면 Controller 위에 @Sl4J를 달면 될 것 같았는데 포인트컷과 함께 사용하려면 새로 클래스를 생성해서 그 위에 달고 내부에 log 를 설정하는 것 같기도 하고.. 좀 더 찾아봐야 겠다

---

SLF4J + LogBack

 

LogBack 은 SLF4J.v1 을 포크하여 만든 것

일반적으로 SLF4J 라 부르는 것은 정확하게는 SLF4J.v2

 

https://tecoble.techcourse.co.kr/post/2021-08-07-logback-tutorial/

 

Logback 으로 쉽고 편리하게 로그 관리를 해볼까요? ⚙️

log 를 많이 남기면 좋지 않을까 생각했었는데, 관리할 때는 몰라도 일반적으로는 아니라고하니 자제해야겠다

근데, log.info 와 logger 의 차이는 뭔지 아직까지 잘 모르겠다

 

---

 

https://velog.io/@smc2315/spring-aop

Spring AOP 동작 원리 및 사용법

AOP 동작 원리를 찾다 보니 발견

생성한 인터페이스를 두 클래스에서 상속 받아서 역할을 분리한 예제가 들어있다

이를 데코레이터 패턴이라고 부른다고 한다

언제 한 번 적용해 보고 싶다

 

AOP 는

핵심기능에 긴밀한 연결을 맺는 부가기능들을 모듈화 하기 위해 등장한 것

즉, 원시적인 형태인 객체화를 위해서 작동되기 때문에 Aspect Oriented Programming 으로 네이밍 된 것이

---

Todo 와 Comment 의 Controller 통합테스트 를 작성하는데, mvc 가 정확히 뭔지 이해가 되지 않아서 막혀버렸다

 

 

회원가입 테스트를 할 때 mockUser 를 적용하는 방식이 아니라 MultiValueMap 을 사용하는데, 그 이유는 

아직 인증되기 전이므로 이미 다 만들어진 mock 을 사용하는 것은 자제해야 한다

MultiValueMap 과 Dto 를 테스트 메서드 내에서 작성하여 사용하는 것도 구별지어 지는데,

이건 초보인 내게는 아직 구별할 필요가 없지만 굳이 비교해 본다면

Form 형식으로 넘어오는가, JSON 데이터 형식으로 넘어오는가로 사용에 구분을 둔다고 한다

---

테스트 코드를 작성할 때 계속 헷갈렸던 부분이 왜 그랬는지를 어렴풋이 알 것 같다

항상 서버의 입장에서 생각했기 때문이었다 (서버 == 나)

 

하지만 테스트 코드를 작성한다는 건

서버에게 내용을 보내고 서버가 처리한 결과를 내가 확인하는 것으로

서버에게 조건을 걸고 작동해 보라고 하며, 나의 예상값을 적고,

나에게 어떤 형식으로 되돌려 달라고 서버에게 요청하고, 내가 적은 게 어떤 형식인지도 서버에게 알려주는 등

서버와 대화하는 것이었던 것 (! 서버 == 나 )

---

TodoController 의 선택한 todo 를 잘 불러오는지와 생성일자 기준 내림차순 조회, 선택 삭제 를 테스트 하려고

mockTodo 객체를 정의하려고 방법을 찾아보니 직접 정의, Setter, Builder 뿐만 아니라

생성자, @Data 를 이용한다고 한다

 

Controller 통합 테스트에서 확인할 수 있는 주요 사항:

1. HTTP 응답 상태 코드 확인: 요청에 대한 응답으로 제대로된 HTTP 상태 코드가 반환되는지 확인합니다. 예를 들어, 200 OK, 404 Not Found, 500 Internal Server Error 등이 해당됩니다.
2. 응답 본문 데이터 확인: 요청에 대한 응답 본문 데이터가 예상한 대로 반환되는지 확인합니다. JSON 형식의 데이터인 경우, 필드 값이나 구조가 올바른지를 검증합니다.
3. HTTP 응답 헤더 확인: 필요한 경우 HTTP 응답 헤더 (예: Content-Type)가 올바른지 확인합니다.
4. 예외 처리: 잘못된 요청이나 예외 상황에서 올바른 예외가 발생하는지를 확인합니다. 예를 들어, 잘못된 요청이 들어왔을 때 400 Bad Request가 반환되는지, 인증 오류가 발생했을 때 401 Unauthorized가 반환되는지를 테스트합니다.
5. 세션 및 인증 처리: 인증이 필요한 경우, 올바른 사용자 인증 정보가 제공되었을 때 요청이 정상적으로 처리되는지를 확인합니다.
6. 다양한 요청 방식 테스트: GET, POST, PUT, DELETE 등 다양한 HTTP 요청 메서드에 대해 테스트를 수행합니다.
7. 입력 유효성 검증: 입력 데이터의 유효성 검사가 제대로 이루어지는지를 확인합니다. 예를 들어, 요청 데이터의 필수 필드가 빠졌을 때 올바른 오류 메시지가 반환되는지를 검증합니다.
8. 세션 관리: 세션 관련 기능이 포함된 요청의 경우, 세션이 올바르게 설정되고 관리되는지를 확인합니다.
9. 트랜잭션 처리: 트랜잭션 관련 작업을 수행하는 요청의 경우, 데이터베이스 상태가 요청의 완료 상태와 일치하는지를 확인합니다.
10. 병목 현상과 성능: 특정 요청이나 작업이 시스템의 성능에 어떤 영향을 미치는지, 병목 현상이 있는지를 확인합니다.
11. 세부적인 비즈니스 로직 검증: Controller에서 호출한 Service 또는 다른 비즈니스 로직이 올바르게 수행되었는지를 검증합니다. 예를 들어, 특정 조건에 따른 데이터 처리가 정확히 이루어졌는지를 확인할 수 있습니다.
12. 인증 및 권한 검사: 사용자의 권한을 테스트하고, 특정 권한이 필요한 요청에 대해 올바른 권한 없음 응답이 돌아오는지 확인합니다.
13. 동시성 및 병렬 처리: 여러 사용자가 동시에 접근할 때의 시스템의 안정성과 동작을 테스트합니다. 예를 들어, 동시 요청이 발생할 때 데이터 일관성이 유지되는지를 검증할 수 있습니다.
14. 로그 및 모니터링: 요청 처리 과정에서 로그가 올바르게 기록되고 있는지를 확인하며, 모니터링 도구를 사용하여 시스템의 상태를 실시간으로 관찰할 수 있습니다.
15. 프론트엔드와의 호환성: 실제 클라이언트(프론트엔드)와의 통합 시나리오를 시뮬레이션하여, API 응답이 프론트엔드에서 예상한 대로 동작하는지를 검증합니다. 이를 통해 UI와 API 사이의 호환성 문제를 사전에 발견할 수 있습니다.

https://m.blog.naver.com/tmondev/220272188977

간단하게 만들어보는 Spring MVC 통합 테스트