백엔드/Spring
-
[Spring] @RequestParam과 @PageableDefault을 동시에 사용할 수 없는 이유백엔드/Spring 2025. 4. 5. 12:35
아래 내용을 알고 있어야함- DispatcherServlet의 동작 방식 회사에서 프론트엔드분이 Swagger 문서상에서는 페이지 요청에 필요한 Pageable 값이 필수값으로 적혀 있는데, 쿼리 파라미터 없이 사용해도 데이터를 받을 수 있으니 쿼리 파라미터 없이 요청해도 문제 없냐고 질문 받았다. (번외로 쿼리 파라미터는 size, page, sort인데 왜 Pageable이라고 적혀있는지도..) 그래서 필수값이 아닌 것을 명시하기 위해 @RequestParam(required=false)와 @PageableDefault을 동시에 사용하려고 했는데, 이러면 요청시 @PageableDefault이 무시되어 쿼리 파라미터 없이 요청하면 Pageable 값이 들어오지 않아 에러가 발생하는 것이었다. 내가..
-
[Spring, JPA] 50% 확률로 통과하는 LocalDateTime 테스트 코드 버그 수정하기백엔드/Spring 2024. 4. 4. 10:11
우테코 프로젝트에 슈뢰딩거의 테스트가 1개 있다. 운이 좋으면 50% 확률로 테스트에 성공하고, 운이 나쁘면 50% 확률로 테스트가 실패한다. 신기하게도 로컬에서는 단 한 번도 테스트가 실패한 적이 없었고, 서비스할 때도 전혀 문제 없었는데, Github Actions에서만 저렇게 빈번하게 실패한다. 1. 데이터 조회 방식 에러가 발생하는 곳은 최신순으로 정렬한 리뷰를 검증하는 테스트 코드에서 나오게 된다. 쿼리문이 길어서 where절만 가지고 왔다. 최신순으로 정렬한 리뷰는 다음 조건에 부합하는 데이터들을 가져오게 된다. 예시를 들어서 설명해보면, 만약 3번 상품에서 가장 마지막에 데이터로 보내준 리뷰가 6번 리뷰라고 가정해보자. 이때 최신순으로 정렬해서 보여줄 경우 다음 페이지는 6번 리뷰보다 더 일..
-
[JPA, MySQL] 같은 유저가 동시 접속을 해서 좋아요를 누르면 동시성 문제가..??백엔드/Spring 2023. 8. 15. 20:35
[리뷰 좋아요 트러블 슈팅] - 1편 : 여러명이 동시에 좋아요를 누르면 데드락과 동시성 문제가..?? - 2편 : 같은 유저가 동시 접속해서 좋아요를 누르면 동시성 문제가..?? 여러명이 동시에 좋아요를 누르면 데드락과 동시성 문제가 해결되어 문제를 해결한줄 알았습니다. 하지만 같은 유저가 500대의 전자기기에 동시 접속을 하여 동시에 좋아요를 누르면 이번엔 NonUniqueResultException이 발생하고 있었습니다. 😭 1개의 데이터만 들어가야 하는데, 10개의 데이터가 들어가서 에러가 발생합니다. MySQL에서도 확인해보니 똑같은 데이터가 10개나 들어있습니다. 1. 테스트 코드 작성하기 이번에는 ExecutorService를 사용해서 테스트를 만들었습니다. 이전에 여러명의 유저로 테스트하는..
-
[JPA, MySQL] 여러명이 동시에 좋아요를 누르면 데드락과 동시성 문제가..??백엔드/Spring 2023. 8. 15. 14:39
[리뷰 좋아요 트러블 슈팅] - 1편 : 여러명이 동시에 좋아요를 누르면 데드락과 동시성 문제가..?? - 2편 : 같은 유저가 동시 접속해서 좋아요를 누르면 동시성 문제가..?? 팀프로젝트에서 리뷰 좋아요 기능에 데드락과 동시성 문제가 발생했습니다. 어디서 데드락이 발생한지는 빠르게 파악했으나.. 근본적인 원인을 찾는데 오랜 시간이 걸렸습니다. 동시성 문제의 경우에는 500명이 리뷰 좋아요를 동시에 눌렀을 때, 좋아요 수가 500개가 아닌 50여개만 나오는 상황입니다. [발생 환경] MySQL 8.0.32 InnoDB [격리 수준] REPEATABLE_READ [데드락 발생 상황] 여러명의 유저가 좋아요 버튼을 전혀 눌러보지 않은 리뷰에서 동시에 좋아요를 누를 경우 발생 좋아요를 이미 눌렀던 리뷰라면 ..
-
[Spring, Test] 가독성 좋은 테스트 코드로 리팩터링하기백엔드/Spring 2023. 8. 13. 16:26
어제 프로젝트가 0.1.0 릴리즈가 되었는데, 그동안 전체적인 테스트 코드 리팩터링을 담당했습니다. 제가 중요하게 생각했던 내용은 메인 테스트 메서드 코드가 읽기 쉽게 되어 있는지에 대한 것이었습니다. 최종적인 목표는 메인 테스트 메서드에는 핵심 내용만 볼 수 있도록 만드는 것입니다. 1. 1차 테스트 코드 리팩터링 지난 달에 프로젝트가 많이 시작되지 않은 상태에서 리팩터링을 1차적으로 진행되었습니다. [1] var 사용하기 https://hello70825.tistory.com/537 [Java] var는 사용해도 되는 것일까? 자동차 경주 미션 2단계의 코드 예시에서는 var를 사용하고 있다. 자바에서 var를 보는 것은 처음이었고, 자바스크립트에서 var는 사용을 지양하라고 나와있어서 선입견 때문에..
-
[트랜잭션] @Transactional 전파 옵션, 프록시 패턴 트러블 슈팅백엔드/Spring 2023. 8. 7. 01:29
카카오 로그인 기능을 프론트엔드 크루인 황펭과 함께 연결하는데, 다른 팀원이 발생시킨 에러 로그인줄 알고 있었다가 나중에 에러 로그를 자세히 읽으면서 발견하게 되었습니다. 하나의 에러에 156줄이나 되는 로그가 나왔는데, 이렇게 긴 에러 로그는 처음 보았고, 당시에 카카오 로그인 기능을 만드는데 CORS 에러가 계속 나와가지고, 이 에러의 존재를 나중에 알게 되어 고쳐나가기 시작했습니다 흑흑.. 중요한 로그는 아래 로그만 보면 됩니다. 읽기 전용 트랜잭션으로 열렸기 때문에 데이터 수정이 불가능하다는 것...!! java.sql.SQLException: Connection is read-only. Queries leading to data modification are not allowed 이때부터 rea..
-
[테스트 격리] 일관된 테스트 격리를 적용하는 트러블 슈팅백엔드/Spring 2023. 8. 6. 01:56
제 팀은 각 테스트 종류마다 테스트 격리를 아래와 같이 진행했습니다. 1. 인수 테스트 : BeforeEachCallback을 사용한 DatabaseCleaner 2. 서비스 테스트 : @Transactional 3. 리포지토리 테스트 : DatabaseCleaner 4. 도메인 테스트 : 없음 여기까지만 보면 바로 문제를 파악하신 분들도 있겠네요 😅 1. 테스트 코드가 실패하다 아무런 문제 없이 프로젝트를 진행하고 있던 어느 날, 느슨해진 테스트 코드 작성에 긴장감을 불어넣는 상황이 발생했습니다. 로그인 기능을 구현하는 브랜치에서 테스트를 돌리는데, 서비스 테스트 1개가 실패하는 것...!! 처음에는 서비스 메서드 자체에 문제가 있는 줄 알았습니다. 하지만 생각해보니 만약 메서드 로직이 잘못 됐으면 테..
-
[Spring] 테스트 코드 수행 시간 최적화하기백엔드/Spring 2023. 5. 8. 22:50
결론 AS-IS: 40여개의 테스트 수행시간 - 13초 ~ 14초 TO-BE: 80여개의 테스트 수행시간 - 2초 1. @SpringBootTest, @WebMvcTest, @JdbcTest 위 세가지는 테스트에서 사용할 수 있는 어노테이션입니다. 각 어노테이션은 생성되는 빈의 수에 따른 차이가 존재합니다. @SpringBootTest는 실제 서버 실행시 필요한 빈을 모두 생성합니다. @WebMvcTest는 웹 환경에 필요한 빈만 생성합니다. @JdbcTest는 Jdbc 환경에 필요한 빈만 생성합니다. 이렇기 때문에 테스트하는 목적에 따라 어노테이션을 잘 활용해서 적용할 수 있습니다. 위 세가지 어노테이션 말고도 다양한 테스트 어노테이션이 있으니 잘 적용하면 시간을 살짝 단축시킬 수 있습니다. [예시] ..