TypeMock Islolator를 사용하지 않고도 완료 할 수 있습니까? 메타 데이터 만 연결 문자열을 전달하는 것과 같은 몇 가지 제안을 온라인에서 찾았습니다.하지만 TypeMock 이외에는 아무 것도 나오지 않았습니다. 단위 테스트를 위해 서비스에 주입 할 수있는 mock ObjectContext를 허용하는 것 같습니다. TypeMock에 대한 $$을 (를) 쓰다듬어 야합니까, 아니면 대안이 있습니까? 아무도 오픈 소스 인 TypeMock과 비슷한 것을 만들 수 없었습니까?EF4 - 단위 테스트를 위해 ObjectContext를 조롱 할 수 있습니까?
나는 조롱하지 않고 쉽게 EF4를 테스트하고 있습니다. 내가 한 작업은 http://elegantcode.com/2009/12/15/entity-framework-ef4-generic-repository-and-unit-of-work-prototype/의 코드를 사용하여 저장소 인터페이스를 작성한 다음 IRepository 인터페이스를 사용하는 InMemoryRepository<T> 클래스를 작성한 것입니다. 그런 다음 IObjectSet<T>을 클래스 내부의 List<T>으로 바꾸고 그에 따라 검색 방법을 변경했습니다.
따라서 단위 테스트를 수행해야하는 경우 DataRepository 대신 InMemoryRepository를 전달하십시오.
-1 Linq2Objects는 Linq2Entities와 다르게 동작합니다. 테스트는
데이터베이스에 액세스하지 않고도이를 전달할 수있는 방법이 없으므로 귀하의 요점은 확실하지 않습니다. 조롱은 Linq2Entities가 항상 유효하고 올바르게 작동한다는 것을 의미하지 않습니다. – KallDrexx
쿼리를 캡슐화하고 실제 데이터베이스와 비교하여 테스트하십시오. 그런 다음 비즈니스 논리를 테스트 할 때 조롱하십시오. 따라서 각 쿼리는 사실에 대해 알고있는 재사용 가능한 구성 요소입니다. 그리고 예상 상태에있는 데이터베이스를 요구하지 않고 비즈니스 로직을 테스트합니다. –
프록시 클래스에서 ObjectContext를 래핑하십시오. 그런 다음 그것을 수업에 삽입하십시오.
예 시도해 보았지만 가능성이 있습니다. 그러나 프록시를 사용하는 이러한 모든 접근 방식에는 고유 한 제한이 있습니다. Linq는 한 가지만 다른 방식으로 작동합니다 (개체에 대한 Linq와 개체 대 Linq). –
TRue,하지만 단위 테스트가 다른 Linq 구현의 차이점을 찾아 낼 것으로 기대하는 것은 Unit Tests의 경우 다소 오버 보입니다. 통합 테스트 분야에서 더 그렇다고 생각하지 않습니까? – SamuelWarren
Linq2Entity 쿼리를 인터페이스 뒤에두고 실제 데이터베이스와 분리하여 테스트하십시오.
쿼리 인터페이스에 대한 mocks로 비즈니스 로직 테스트를 작성하십시오. 린크가 당신의 비즈니스 논리에 피를 흘리지 않게하십시오!
RepositoryPattern을 사용하지 마십시오!
내가 저장소 패턴이 질문에 대한 유일한 해답이라고 생각하지 않습니다
나는이 대답을 좋아했다 (그것은 확실히 문제 방지) - 나는 기존의 코드베이스에 테스트를 도입 더 적절한 생각을 Creating Interface for ObjectContext
내가 본 한 가지 제안은 db에 대해 다시 테스트하는 규칙을 어기는 것입니다. 그 사람은 CreateDatabase()를 사용하여 파리에서 "모의"db 인스턴스를 로컬로 생성한다고 말했습니다. 일반적으로 이전 프로젝트에서이 규칙을 위반했을 때이 문제를 피하고자합니다. ~ 600 테스트까지는 괜찮 았지만 2000 년 테스트를 마친 후에는 진정한 TDD에서는 전혀 쓸모가 없었습니다. 테스트를 "일괄 처리 모드"로 실행 한 결과 (실행 시간이 5 분 이상 소요되었습니다). –