나는 근본적으로 잘못된 것을해야합니다.모의 자료가있는 모의 저장소 vs. 실제 저장소
저는 리포지토리를 구현 한 다음 조롱 된 데이터로 테스트합니다. 모든 것이 잘됩니다.
이제 도메인 객체를 테스트하여 모의 저장소를 가리키고 싶습니다.
하지만 '실제'리포지토리의 논리를 모의 객체로 다시 구현해야하거나 논리를 캡슐화하고 리포지토리 (실제 또는 모의 객체)와 상호 작용하는 '도우미 클래스'를 만들어야한다는 것을 알고 있습니다. 그럼 난 그 너무 테스트해야합니다.
그래서 내가 무엇을 놓치고 있습니까? 모의 데이터로 실제 데이터 저장소를 사용할 수있을 때 모의 저장소를 구현하고 테스트해야하는 이유는 무엇입니까?
EDIT : '조롱 된 데이터'에 의해 명확히하기 위해 실제 데이터베이스에 도달하지 않았습니다. 알려진 데이터를 반환하는 실제 리포지토리 아래에 삽입 할 수있는 'DB 모의 계층'이 있습니다.
어쩌면 당신의 추상화를 혼합 할 수 있습니다. 어쩌면 당신의 도메인 객체에 당신의 이야기가 있어야만하는 도우미와 논리의 일부일 것입니다. 리파지토리는 CRUD 인터페이스를 구현해야합니다. 따라서 도메인 논리는 저장소에서 8 가지 작업을 사용해야합니다. 양호한 검색 및 잘못된 검색 (예외 발생)은 8 개 중 2 개입니다. 한 가지 테스트는 Bad 객체가 도메인 객체에서 어떻게 다루어 지는지입니다. 나머지 테스트는 Good 검색을 테스트해야합니다.
이유를 구현하고 내가 조롱 데이터로 실제 것들을 사용할 수 있습니다 때 모의 저장소를 테스트?
나는 정말로 당신이 갖고 있어야한다고 생각하는 코드 커버리지가 얼마나 많은지 알기 쉽다. 리포지토리가 건전하고 테스트 용으로 사용할 수 있다고 생각되면 찾아보십시오. 아마도 저장소 단위 테스트는 모의 데이터베이스 단위 테스트 이전에 실행될 수 있으므로 테스트를 위해 실제 저장소를 사용하고 테스트가 여전히 유효하다는 확신을 가질 수 있습니다.
모의 데이터를 설명하지 못했지만 좋은 지적입니다. 원본 질문을 세부 사항과 함께 편집했습니다. – n8wrl
DB 모의 레이어에 어떤 문제가 있습니까? 나에게 완벽하게 합리적인 접근법처럼 들린다. –
단위 테스트는 버그가 발생할 경우 검색 시간을 줄이기 위해 테스트 된 요소 -> 테스트 데이터 경로를 최소화하기위한 것입니다. 버그는 테스트하는 루틴이나 테스트 단위와 그 밖의 아무것도 아닙니다. 운영 체제 또는 컴파일러 ...하지만 이들은 매우 드문 경우).
이제 데이터베이스 접근기 모듈을 만들었다 고 가정 해보십시오. 모듈이 정상적으로 작동하는 것 같습니다. 그런 다음 데이터베이스에서 읽는 구성 판독기를 만듭니다. 모의 데이터베이스 접근 모듈 단위 테스트 대신 데이터베이스 테스트 유닛의 모의 구성 데이터 위에 실제 데이터베이스 모듈을 사용합니다. 그것은 여전히 잘 작동하는 것 같습니다. 이제 config 판독기 유닛이 반환 한 config 객체를 사용하는 GUI 레이어를 추가합니다. "끓인"설정 데이터를 조롱하는 대신 실제 작동하는 실제 모듈을 사용합니다. 이제 GUI가 특정 값으로 작동하지 않습니다. 오류는 어디에 있습니까? GUI, 설정 판독기, 데이터베이스 접근 자 또는 모의 데이터베이스의 값?
즉, 작성중인 코드를 테스트하는 것이 아니라 실제 리포지토리 시스템도 테스트하는 것입니다. 버그가 발견되면 분석 할 추가 계층이 있습니다.
이것은 정말로 나를 생각있어 - Gutzofter 감사합니다 – n8wrl
당신은 환영합니다 – Gutzofter