첫 번째 방법을 사용하고 있지만 언급 한 문제를 해결할 수있는 약간 다릅니다.
DAO에 대한 테스트를 실행하는 데 필요한 모든 것은 소스 제어에 있습니다. DB를 생성하는 스키마와 스크립트가 포함되어 있습니다 (도커는 매우 유용합니다). 임베디드 DB를 사용할 수 있다면 속도로 사용합니다.
설명 된 다른 접근 방식과의 중요한 차이점은 테스트에 필요한 데이터가 SQL 스크립트 또는 XML 파일에서로드되지 않는다는 것입니다. 유틸리티 함수 / 클래스를 사용하여 응용 프로그램에서 모든 것이 (실제로 일정한 일부 사전 데이터 제외) 생성됩니다.
주요 목적은 테스트에 사용되는 데이터를 만드는 것입니다
- 시험에 매우 가깝다
- 명시 적 (데이터에 SQL 파일을 사용하면 어떤 테스트에서 어떤 데이터가 사용되는지 확인하기가 매우 어려워 짐)
- 관련없는 변경으로부터 테스트를 분리합니다.
기본적으로 이러한 유틸리티를 사용하면 테스트 자체에서 테스트에 필수적인 것만 선언적으로 지정하고 관련이없는 것을 생략 할 수 있습니다.
이 실제로 무엇을 의미하는지 몇 가지 아이디어를 제공하기 위해 함께 작동 일부 DAO에 대한 테스트 고려 Comment에의 Post쓴들 Authors. 이러한 DAO에 대한 CRUD 연산을 테스트하려면 DB에 일부 데이터를 작성해야합니다. 테스트는 다음과 같습니다.
@Test
public void savedCommentCanBeRead() {
// Builder is needed to declaratively specify the entity with all attributes relevant
// for this specific test
// Missing attributes are generated with reasonable values
// factory's responsibility is to create entity (and all entities required by it
// in our example Author) in the DB
Post post = factory.create(PostBuilder.post());
Comment comment = CommentBuilder.comment().forPost(post).build();
sut.save(comment);
Comment savedComment = sut.get(comment.getId());
// this checks fields that are directly stored
assertThat(saveComment, fieldwiseEqualTo(comment));
// if there are some fields that are generated during save check them separately
assertThat(saveComment.getGeneratedField(), equalTo(expectedValue));
}
테스트 데이터가있는 XML 파일이나 SQL 스크립트에 비해 몇 가지 장점이 있습니다.
- 코드를 유지 관리하는 것이 훨씬 쉽습니다 (예 : Author와 같이 많은 테스트에서 참조되는 일부 엔터티에서 필수 열 추가는 많은 파일 / 레코드를 변경하지 않아도되며 빌더 및 / 또는 팩토리 만 변경하면 됨)
- 특정 테스트에 필요한 데이터는 다른 파일이 아닌 테스트 자체에 설명되어 있습니다. 이 근접성은 테스트 이해를 위해 매우 중요합니다.
롤백 및 커밋
테스트가 실행될 때 커밋하는 것이 더 편리하다는 것을 알았습니다. 먼저 일부 효과 (예 :DEFERRED CONSTRAINTS 커밋이 발생하지 않으면 :)를 확인할 수 없습니다. 둘째, 테스트가 실패하면 롤백에 의해 되돌려지지 않으므로 DB에서 데이터를 검사 할 수 있습니다.
원인으로 인해 테스트에서 데이터가 손상 될 수 있고 다른 테스트에서는 실패 할 수 있다는 단점이 있습니다. 이를 해결하기 위해 테스트를 분리하려고합니다. 위의 예에서 모든 테스트는 새로운 테스트 Author를 생성하고 이와 관련된 다른 모든 엔티티는 생성되므로 충돌이 거의 없습니다. 잠재적으로 손상 될 수 있지만 DB 수준 제약 조건으로 표현할 수없는 나머지 불변량을 처리하기 위해 모든 단일 테스트 후에 실행될 수있는 잘못된 조건에 대해 프로그래밍 방식 검사를 사용합니다 (CI에서 실행되지만 일반적으로 성능을 위해 로컬로 꺼집니다) 원인).