어떤 사람들 은 통합 테스트가 모든 종류의 나쁘고 잘못되었다고 주장합니다. 모든 것이 반드시 단위 테스트를 거쳐야합니다. 즉, 의존성을 조롱해야합니다. 여러 가지 이유로 항상 좋아하지 않는 옵션.
어떤 경우에는 단위 테스트가 단순히 아무것도 입증하지 못한다는 것을 알았습니다.
다음과 같은 (사소하고 순진한) 리포지토리 구현 (PHP)을 예로 들어 보겠습니다.
class ProductRepository
{
private $db;
public function __construct(ConnectionInterface $db) {
$this->db = $db;
}
public function findByKeyword($keyword) {
// this might have a query builder, keyword processing, etc. - this is
// a totally naive example just to illustrate the DB dependency, mkay?
return $this->db->fetch("SELECT * FROM products p"
. " WHERE p.name LIKE :keyword", ['keyword' => $keyword]);
}
}
이 저장소가 실제로 다양한 키워드와 일치하는 제품을 찾을 수 있음을 테스트에서 증명하고 싶다고 가정 해 봅시다.
실제 연결 개체와의 통합 테스트가 부족하여 이것이 실제로 실제 쿼리를 생성하고 있다는 것을 어떻게 알 수 있습니까?
단위 테스트에서 연결 개체를 조롱 해야하는 경우 "예상 쿼리를 생성합니다"와 같은 것만 증명할 수 있지만 실제로 작동 한다는 의미는 아닙니다 . 즉, 아마도 쿼리를 생성하고 있습니다 나는 예상했지만 어쩌면 그 쿼리는 내가 생각하는 것을하지 않을 것입니다.
다시 말해, 생성 된 쿼리에 대한 어설 션을 만드는 테스트 인 것 같습니다. findByKeyword()메소드가 어떻게 구현 되었는지 테스트하기 때문에 실제로는 가치 가 없지만 실제로 작동 한다는 것을 증명하지는 않습니다 .
이 문제는 리포지토리 또는 데이터베이스 통합에만 국한되지 않습니다. 모의 (test-double) 사용에 대한 주장은 상황에 관계없이 구현 방식 만 입증하는 많은 경우에 적용되는 것으로 보입니다. 실제로 작동합니다.
이런 상황을 어떻게 처리합니까?
이런 경우 통합 테스트가 실제로 "나쁜"가요?
나는 한 가지를 테스트하는 것이 낫다는 점을 알고 있으며 통합 테스트가 왜 무수한 코드 경로를 가져 와서 모두 테스트 할 수 없는지 이해하지만 목적이 유일한 서비스 (예 : 저장소)의 경우 다른 구성 요소와 상호 작용하기 위해 통합 테스트없이 어떻게 실제로 테스트 할 수 있습니까?
