- 전체보기(104)
- Java(76)
- 이펙티브 자바(44)
- Spring(19)
- 객체지향(7)
- JPA(6)
- docker(6)
- 우아한테크코스(4)
- junit(4)
- 디자인패턴(4)
- 독후감(3)
- 알고리즘(3)
- JUnit5(3)
- 프리코스(3)
- python(3)
- gradle(3)
- 단위 테스트(2)
- Querydsl(2)
- Nginx(2)
- Converter(2)
- linux(2)
- sql(2)
- webclient(2)
- 테스트(2)
- algorithm(2)
- ArgumentResolver(2)
- Backend(2)
- Web Server(2)
- test(2)
- 메멘토패턴(1)
- CS(1)
- filter(1)
- 프로토콜(1)
- build(1)
- 중재자 패턴(1)
- 리팩토링(1)
- jackson(1)
- byte buddy(1)
- JVM(1)
- Spring boot(1)
- 정렬(1)
- aws(1)
- mediator(1)
- 구현(1)
- devops(1)
- Groovy(1)
- exception(1)
- 배열(1)
- Monotonic Queue(1)
- UnionFind(1)
- LomBok(1)
- cron(1)
- type-script(1)
- 개발 일지(1)
- S3(1)
- logback(1)
- ObjectMapper(1)
- chain of reponsibility(1)
- ssl(1)
- 직렬화(1)
- jacoco(1)
- EntityManager(1)
- presigned url(1)
- Sliding Window(1)
- 데코레이터(1)
- oracle(1)
- bean(1)
- oauth2(1)
- JSONParser(1)
- REST Docs(1)
- Deque(1)
- 웹 서버(1)
- Oracle-Cloud(1)
갯수 카운트와 join을 같이 써서 나타난 문제 해결하기
발생한 문제 나의 카테고리 조회 로직은 다음과 같다 그러나 해당 로직은 cardId.countDistinct()가 조회에 문제가 있었다. 도메인을 설계할때 삭제 상태를 나타내는 isDeleted 속성을 뒀는데 카드를 삭제하면 isDeleted = true가 되고 실제로 데이터를 삭제하지는 않는다. 그러나 위의 쿼리대로라면 card의 isDeleted가 true가 되더라도 count시 cardId를 카운트한다. 그 이유는 leftJoin시 cardId가 null이 아니기 때문에 isDeleted와 상관없이 카운트하기 때문이다. where절에 추가했지만 또 다른 문제가 발생 테스트 코드를 짜고 where 절에 단순히 card의 isDeleted=false로 필터해버리면 된다고 생각했다. 그러나 결과는 예상대로 나오지 않았다. 
Querydsl 테스트 코드 개선하기
기존 테스트 코드 문제점 테스트 코드의 코드 수를 줄이기 위해 given을 전역 상태로 만들어서 테스트를 수행했다. https://github.com/Almondia/meca-backend/commit/084fb5fa72c14e6657e49e754506c9d5c75a2529 그러나 주어진 데이터를 공통으로 사용하는 방법은 test 코드에서 given 빠지고 when과 결과만을 판독하기 떄문에 테스트 메서드 내부의 코드의 길이는 짧아졌지만 오히려 그 때문에 여럿 문제가 발생했다. 1. 모든 테스트 코드를 만족하기 위한 테스트 데이터는 가독성을 떨어뜨린다 unit test 마다 다양한 상황이 존재할 수 있다. 이에 맞는 데이터를 전부 고려해서 설계해야 하기 때문에 given에 주어지는 데이터가 무거워진다. 위의 코드의 데이터가 작성되지만 주어진 데이터 코드가 무엇을 의미하는 지는 쉽게 이해하기 쉽지 않다. 이 때문에 매번 테스트 코드를 추가하거나 작성할 때