2013-11-13 4 views
2

스프링 데이터 JPA 1.4.2가 My Repository 레이어로 사용되는 QueryDSL 3.2.4를 사용하고 있습니다. 나는 웹 폼 객체 (스프링이 검색 폼을 바인드하는 간단한 Bean)를 가져 와서 QueryDSL Criteria 객체를 생성 한 다음 비즈니스/데이터 계층에 전달하여 쿼리를 실행한다.QueryDSL 기준 생성 단위 테스트는 어떻게합니까?

저는이 세대의 Criteria 객체를 단위 테스트하는 가장 좋은 방법을 찾아 내려하고 있습니다. 검색 대상에 따라 여러 가지 필드 조합이 쿼리에 포함됩니다 (기본적으로 일반적인 검색 양식입니다. 필드는 비어있을 수 있지만 비어 있지 않은 필드는 검색 기준을 나타내며 일부 필드는 검색 조건을 나타냅니다). 필드에는 "완전 일치", "시작"또는 "포함"등의 몇 가지 추가 옵션이있을 수 있습니다.

Spring Data JPA tutorial은 JPA Criteria API에 비해 QueryDSL을 사용하도록 권장합니다. .toString()을 비교하여 QueryDSL을 단위 테스트 할 수 있습니다. 그래서, 제가 지금 기대하고있는 방법입니다. 그 결과 Criteria 객체의 toString()이 내가 테스트하려고하는 쿼리에 대해 합리적인지를 확인하는 것입니다.하지만 어떻게 " "toString을 사용하면 원하는 쿼리를 미리 작성하지 않고 toString이 무엇인지 알 수 있으므로 훌륭한 테스트는 아닌 것처럼 느껴질 수 있으며 QueryDSL의 내부 구조를 기반으로 변경 될 수 있습니다. (필자는 toString을 주로 디버깅 보조 도구라고 생각하지만, 누군가가 QueryDSL이 toString() 메소드를 작성하는 방법에 대한 스펙을 지적하고 사용 방법의 일부이거나/라이브러리의 사용법을 테스트하면이 접근법으로 더 행복해 질 것이라고 생각합니다.) 더 좋은 점이 있기를 바랍니다.

또 다른 StackOverflow 질문 "How do I unit test the querydsl query inside the given method?"이 있지만 전체 쿼리를 테스트하고 모의 EntityManager가 필요합니다. 나는 단지 Criteria 부분을 테스트하기를 희망하고있다. 그래서 나는 그것보다 간단한 접근법이 필요하다. Criteria를 사용하는 Query를 모의하고 EntityManager를 사용하여 모의 실험을해야한다. 나에게 내가 단순히 Criteria 객체를 올바르게 만들고 있다고 단정 짓기 위해 노력하고있는 것보다 더 복잡하다.

필자는 내가 올바른 기준을 만들고 있다고 테스트하려는 유일한 사람이 될 수없는 것처럼 느낍니다. 내가 뭘 잘못하고 있는지 또는 어떻게 단위 테스트를 할 수 있는지에 대한 통찰력을 가져 주셔서 감사합니다.

답변

2

내 접근 방식은 간단한 쿼리로 시작한 다음 점점 더 복잡한 "샘플"을 수집하는 것입니다. 네, 실제 쿼리 결과를 사용하고 있습니다. 그걸 안구 테스트 한 후 단위 테스트의 expected 부분으로 복사하고 있습니다.

위대한 테스트는 아닙니다. 목적은 약간 다릅니다 : 그것은 당신이 기대하는 것을 문서화합니다.

무언가가 변경되면 테스트가 실패하기 시작하며 "어제 예상했던 것"과 "오늘받는 것"사이에 차이점을 만들 수 있습니다.

여기에는 코드에서 수행 할 수있는 내용도 나와 있습니다. 프로덕션의 버그가 발견되면 새로운 단위 테스트를 작성하고 실패한 다른 단위 테스트를 시도 할 수 있습니다. 이것은 변화의 영향을 잘 이해할 수있게 해줍니다. (변화가 1 번 + 테스트의 90 %가 실패했습니다. 핫스팟을 찾았습니다.)

버그를 수정하면 패턴이 일반적으로 잘못되어 대형 쿼리 작성기에서 사용하는 하위 빌더와 같은 특정 단위 테스트로 해당 위치를 보호하십시오.

몇 가지 복잡한 쿼리의 경우 단위 테스트를 만들어 실제로 작동하는지 확인합니다. 그것은 나에게 빠른 "문자열 비교"단위 테스트가 작동한다는 자신감을줍니다.

2

실제 EntityManager가있는 모든 QueryDSL 코드와 실제 메모리가 H2 database 인 'unit'테스트를합니다. EntityManager를 조롱하지 않고 생성 된 JPQL을 검사하지 않고 쿼리가 실제로 예상 한 객체를 반환하는지 테스트합니다.

단위 테스트 순진 주의자는 이것이 진정한 단위 테스트가 아니라고 주장 할 수 있지만 작동하는 코드가 있으며 충분히 빠릅니다.

<jdbc:initialize-database data-source="dataSource"> 
    <jdbc:script location="classpath:com/foo/sql/db-schema.sql"/> 
</jdbc:initialize-database> 
:

이는 비교적 쉽게 스프링 embedded database support 달성된다