단위 테스트 사례를 작성할 때 모의 객체를 작성하는 이유는 무엇입니까?

우리는 현재 프로젝트에서 단위 테스트 사례를 작성하고 있습니다. 데이터베이스 메소드 구현이 존재하며 제대로 작동하고 있습니다. 이 경우 왜 모의 객체를 작성해야합니까? 특별한 이유가 있습니까? DAO 구현을 직접 테스트 할 수없는 이유는 무엇입니까?

데이터베이스에 대한 호출을 모방해서는 안됩니다. 왜냐하면 목적을 달성 할 수 없기 때문입니다. 예를 들어, 모의 대상은 서비스 계층에서 DAO를 호출하는 것입니다. Mocking을 사용하면 격리 된 방법으로 테스트 할 수 있습니다.

다음과 같은 아키텍처로 식당 시뮬레이션이 있다고 가정하십시오.

Cook <=> Server <=> Customer

각 계층을 독립적으로 테스트하려고합니다. 여기에 Server서비스 계층이 있으며 CookDAO로 생각할 수 있습니다. 는 Server당신이 테스트하는 동안 조롱 할 것입니다 Customer, 그리고는 Cook을 테스트하는 동안 모의를 원하는 것입니다 Server. 그러나 Cook단위 테스트는 고무 타이어가 아닌 햄버거를 주문했을 때 구현이 햄버거를 반환하는지 확인해야합니다.

데이터베이스와 함께 businesslogic을 테스트해도됩니다. 그러나 이러한 테스트를 nunit 또는 junit 또는 phpunit을 사용하여 실행하더라도 통합 테스트 라고 합니다.

단위 테스트는 개별 테스트 (즉, 데이터베이스가없는 buisinesslogic)가 중요한 특수화 된 테스트입니다. Mocks / fakes / stups는이 격리를 시행하는 데 사용됩니다.

간단히 : 데이터베이스 내용이 아닌 실제 DAO를 테스트합니다.

DAO Person 클래스에 getByName () 메소드가 있다고 가정하십시오. 테스트를 작성하고 Person.getByName ( "John Smith")을 호출하십시오. 누군가 데이터베이스에서 John의 레코드를 제거했기 때문에 테스트가 실패했다고 가정하십시오. 이제 모든 CI 소프트웨어와 감독자 / 검토 인은 귀하의 소프트웨어에 결함이 있다고 주장 할 수 있지만 실제로는 그렇지 않습니다. DB를 조롱하면 DAO가 올바른 테이블에서 올바른 행을 제공하면 DAO가 작동한다는 것을 증명할 수 있습니다.

데이터베이스 자체를 실제로 테스트하려는 경우, 즉 특정 DAO 메서드를 실행하면 데이터가 특정 상태에 놓이는 경우에도 가능합니다. 또한 데이터베이스가 방탄 무결성을 제공 할 것으로 기대할 수없는 엉뚱한 데이터 모델 (EAV, 중첩 트리 세트)을 사용하면 실제로 도움이됩니다. 인생을 더 편하게하기 위해 DBUnit 을 살펴보십시오 .

또 다른 이유는 실제로 데이터베이스 명령을 실행하는 실행 시간을 피하기위한 것입니다. 별로 보이지 않을 수도 있지만 연결 설정 및 해제의 오버 헤드로 인해 결국 모의 객체를 사용하는 것과 비교하여 테스트 스위트를 실행하는 전체 시간이 크게 늘어날 것입니다.

테스트중인 클래스를 분리합니다. 그렇지 않으면 테스트에 실패하면 테스트중인 클래스 또는 문제 중 하나에 문제가 있는지 어떻게 알 수 있습니까?