github-actions[bot]
commented
1 year ago Test Coverage Report
| Overall Project | 66.67% -0.53% |
:disappointed: |
|---|---|---|
| Files changed | 84.76% | :heart_eyes: |
| File | Coverage | |
|---|---|---|
| ShortFormController.java | 100% | :heart_eyes: |
| ShortFormService.java | 100% | :heart_eyes: |
| Shelter.java | 88.89% | :heart_eyes: |
| Pet.java | 71.52% -10.13% |
:heart_eyes: |
| ShelterController.java | 70.37% | :heart_eyes: |
| PetController.java | 65.22% | :heart_eyes: |
| PetVideo.java | 62.34% | :heart_eyes: |
xGreenNarae
작업 내용
[실수] Production Profile에 누락되어 있던 Pageable 입력 값을 기본 1로 잡아주는 설정을 추가했습니다.
[실수] PetAge 변환 시 year가 0인 경우에 대한 테스트 동작 변경이 누락되어 있어서 추가했습니다.(Autoparams의 테스트 데이터 랜덤생성으로 우연히 얻어걸렸는데, 애초에 테스트 케이스를 확실하게 넣어뒀어야 해서 안좋은건지 아니면 예상하지 못했던 테스트케이스가 발생해서 잡아냈기 때문에 좋은건지 모르겠네요)
[중요]
@PageableDefault에서 기본값을 1로 잡아주면,spring.data.web.pageable.one-indexed-parameters: true설정과 충돌하게 되네요. 기본(no-parameter)입력으로 요청 시 page가 2가 됩니다. 따라서 0으로 잡아둬야합니다. 명시적으로 1로 입력하고 요청할 시에는 그대로 1이 됩니다. 구체적인 이유는 찾아보지 않았습니다.[사소한 개선] ShortForm API 문서에 pageable 그대로 노출되어 있는 api 하나 수정했습니다.(#198)
[기본기 부족] OneToMany 동작을 제대로 이해하고 fk가 들어가도록 로직을 수정했습니다. 결론적으로
@OneToMany사용의 장점은 아직 크게 모르겠지만, 지금처럼 기존 테이블에서 떨어져나가 새로운 테이블로 확장되어 나가는 경우에 유지보수 비용을 크게(매우 압도적으로, 또는 비현실적인 것을 현실적으로) 줄여주는 것 같습니다.[깨달음] DataJpaTest를 위한 BaseClass에서 반환된 entity를 콘솔에 출력하는 로직을 중복작성하지 않으려고 모듈화 해뒀는데, 여기서 I/O Exception이 발생하기 때문에 throw를 명시해줘야 합니다. 근데 그러면 사용하는 상위 로직에서 계속 반복적으로 throw 명시해줘야 합니다. 이걸 없애려고 catch구문으로 예외를 잡은다음에 log만 찍고 그대로 먹어버렸습니다. 결과적으로 Infinite Recursion(양방향 순환참조 시) 발생하는데 놓칠 뻔 했습니다. Exception을 catch했으면 적절하게 처리한 뒤에 최소한 Runtime Exception으로 다시 던져주도록 해야겠습니다. 발생하고 있는 순환참조(test에서 console에 찍기 때문. 실제로는 dto로 변환하기 때문에 발생하지 않겠지만) 문제 해결하는 방법으로, 그냥 습관적으로
OneToMany - ManyToOne관계에서JsonPropertyManagedReference, BackReference쌍으로 달아둔다고 생각하면 좋을 것 같습니다.[실제 중요한 문제 해결] N+1쿼리가 발생하든, Lazy Loading으로 Entity들을 추가로 불러와야하는 상황에
@Transactional누락으로 서버에서 버그가 터졌습니다. 추가했고, short-form domain의 N+1 쿼리도 join fetch로 해결했습니다. 그냥 가능하면@Service는@Transactional 또는 readonly와 함께 사용하는 것이 안전한 스프링 사용습관이 되지 않을까 생각했습니다.ShortForm domain에서 PetRepository를 참조하고 있는데, Pet table을 참조하되, Repository는 별도로 사용하도록 분리했습니다. 결국 마지막에는 의존성 흐름이 DB에서 만나게 되지만, 도메인 분리의 중요한 점이 "Application Code"를 독립적으로 분리하여 확장해나갈 수 있다는 목적으로 보자면 이 쪽이 좋은 practice 인 것 같습니다.
아직 해결하지 못한 것
production서버는 root레벨에서 모든 log를 파일에 기록하도록 되어있으나, 어째서 인지
[ExceptionHandlerExceptionResolver] Resolved [org.hibernate.LazyInitializationException: ...가 로그파일에 기록되지 않았습니다. 추가로 알아보겠습니다.Acceptancetest - ShortFormTest에서 query log가 제대로 안 찍히는 것 같습니다.(추측) N+1 쿼리를 해결하기 위해서, 테스트 로그로는 확인이 안되서 운영서버에 붙여서 해결했습니다. 이 부분도 더 알아보겠습니다.Close #198 , Close #207