일부 DAO를 사용하여 데이터베이스에 대한 호출을 수행하는 메소드가 있습니다.mock 또는 dbunit을 사용하여 데이터베이스에 액세스하는 방법을 테스트해야합니까?
모의 메커니즘을 사용하여 데이터베이스를 관리하지 않아야하고 모든 DAO 메소드를 모의 해 주어야합니까? 아니면 dbunit (또는 일부 동급)를 사용하여 메모리에 데이터베이스 (예 : hsqldb)를 초기화하여 테스트해야합니까?
각 방법 (mock 대 dbunit)에 대한 장단점이 있습니까?
확실한 대답은 힘든 질문입니다. 그러나 필자가 제안하고 일반적으로 선호하는 것은 DAO 자체가 내장 데이터베이스 또는 외부 테스트 데이터베이스 (통합 테스트)에 대해 테스트하여 DAO가 일종의 읽기 데이터베이스에 대해 제대로 작동하는지 확인하는 것입니다.
그런 다음 DAO를 사용하는 구성 요소의 경우 테스트를 분리하여 데이터베이스를 명시 적으로 사용하지 않아도됩니다.
이 접근법의 단점은 테스트를 위해 사용할 수있는 일종의 임베디드 또는 다른 DB가 있어야한다는 것입니다.
DAO 단위 테스트를 조롱 할 수 있습니다. 그러나, 당신은 당신의 조롱이 DB가 제공 할 것을 진정으로 대표 할 것이라는 것을 완전히 확신하지 못합니다.
희망이 도움이됩니다.
데이터베이스를 테스트하려고합니다. 나는이 문맥에서 모의 (mock)이 어떤 의미인지를 보지 못했다. DAO가 작동 중임을 알게되면, DAO가 작동하고있는 상황에서 mock을 사용하는 서비스에 mock을 주입합니다.
그동안 데이터베이스를 테스트하십시오. 임시 테스트 데이터베이스를 작성하거나 모든 테스트를 트랜잭션화할 수 있습니다. 테스트 작업 단위를 설정하여 실행하고, 유효성을 검증하고 롤백 할 수 있습니다.
일반적으로 mock obejcts를 사용하는 것이 좋습니다. 데이터베이스 액세스는 실제로 성능이 좋지 않고 많은 시간을 들여야합니다. 4000 단위 테스트가있는 프로젝트가 있었는데, 전체 테스트를 실행하는 데 3 시간 이상 걸렸습니다. 설정 및 테스트는 각 테스트 전과 후에 데이터베이스에 액세스합니다.
dbunit에 관해서 나는 그것을 사용하여 정말 좋은지 아닌지를 말할 수 없지만 단위 테스트에서 데이터베이스 액세스를 피할 것이라고 말하면 논리 단위로만 제한되어야합니다.
나는 동의한다, 속도는 근본적이다. 모든 단위 테스트를 실행하는 데 몇 초가 걸리면 개발자가 실행하지 않을 이유를 찾을 수 있습니다. ... 그것은 동일한 테스트 프레임 워크를 사용하여 end-to-end 테스트를 작성할 수 없다는 것을 의미하지는 않습니다. 그러나 실제 데이터베이스 (또는 실제 서버)를 치는 모든 것은 수용 테스트로 이동해야합니다. –