발생한 문제 나의 카테고리 조회 로직은 다음과 같다 그러나 해당 로직은 cardId.countDistinct()가 조회에 문제가 있었다. 도메인을 설계할때 삭제 상태를 나타내는 isDeleted 속성을 뒀는데 카드를 삭제하면 isDeleted = true가 되고 실제로 데이터를 삭제하지는 않는다. 그러나 위의 쿼리대로라면 card의 isDeleted가 true가 되더라도 count시 cardId를 카운트한다. 그 이유는 leftJoin시 cardId가 null이 아니기 때문에 isDeleted와 상관없이 카운트하기 때문이다. where절에 추가했지만 또 다른 문제가 발생 테스트 코드를 짜고 where 절에 단순히 card의 isDeleted=false로 필터해버리면 된다고 생각했다. 그러나 결과는 예상대로 나오지 않았다. ![](https://velog.velcdn.com/images/e1psycongr00/post/5b7ad6e0-11db-4118-8c

자바로 알고리즘 문제들 테스트하기 자바로 요즘 알고리즘 풀이 사이트 문제 형식에 제공되는 파라미터를 기입하는게 생각보다 오래 걸리고 귀찮다. 대표적인 예로 프로그래머스가 있는데 프로그래머스의 입력은 다음과 같이 이루어 진다. 이걸 java junit으로 테스트하려면 \[ 와 \] 를 {}로 바꾸어서 기입해야한다. 문제가 2차원 배열이면 이것은 더 복잡해진다. 실제 자바에서 테스트하려면 다음과 같이 써야 한다 이런 코드를 여러개 작성해야 한다. 그러나 솔직히 시간이 없는데 대괄호를 중괄호로 바꿔서 테스트 코드에 넣어보고 일일히 코드 짜고 하는 것은 실제 시험에서 부담감이 심하다. 이를 해결하기 위해 최대한 적은 코드로 많은 코드를 통합 테스트 할 수 있어야 한다. @Paramete

더티 체킹 https://jojoldu.tistory.com/415 더티 체킹에 대해 간략하게 잘 설명되어 있는 블로그다. > 더티 체킹이란 트랜잭션 내에서 영속화 상태의 엔티티의 데이터가 변경되면 별다른 요청 없이 트랜잭션 종료시 변경값으로 update 된다. 더티 체킹은 JPA의 핵심 기술이라 볼 수 있다. 기본적으로 영속화를 하면 엔티티는 영속 컨텍스트에 저장되며 entityManager가 이를 관리한다. managed(영속)상태의 데이터는 커밋시에 반영되며 수정 변경된다고 해서 바로 쿼리를 호출하지 않는다. 이렇게 쿼리 생성 및 동작을 지연시키는 방법을 통해 성능을 올릴 수 있다.(db에 데이터를 넣고 조회할 때 커넥션과 projection 작업은 보통 application보다 무거운 작업이다) 더티 체킹은 detach나 비영속 상태에서는 동작하지 않는다. 더티 체킹 테스트에서 발생한 문제 카테고리 엔티티를 수정하는 코드이다. 그리고 이 코드를 테스트

기존 테스트 코드 문제점 테스트 코드의 코드 수를 줄이기 위해 given을 전역 상태로 만들어서 테스트를 수행했다. https://github.com/Almondia/meca-backend/commit/084fb5fa72c14e6657e49e754506c9d5c75a2529 그러나 주어진 데이터를 공통으로 사용하는 방법은 test 코드에서 given 빠지고 when과 결과만을 판독하기 떄문에 테스트 메서드 내부의 코드의 길이는 짧아졌지만 오히려 그 때문에 여럿 문제가 발생했다. 1. 모든 테스트 코드를 만족하기 위한 테스트 데이터는 가독성을 떨어뜨린다 unit test 마다 다양한 상황이 존재할 수 있다. 이에 맞는 데이터를 전부 고려해서 설계해야 하기 때문에 given에 주어지는 데이터가 무거워진다. 위의 코드의 데이터가 작성되지만 주어진 데이터 코드가 무엇을 의미하는 지는 쉽게 이해하기 쉽지 않다. 이 때문에 매번 테스트 코드를 추가하거나 작성할 때