Algunas personas sostienen que las pruebas de integración son todas malas y malas - todo debe ser probado por unidades, lo que significa que tienes que simular las dependencias; una opción que, por diversas razones, no siempre me gusta.
Encuentro que, en algunos casos, una prueba de unidad simplemente no prueba nada.
Tomemos como ejemplo la siguiente implementación de repositorio (trivial, ingenua) (en 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]);
}
}
Supongamos que quiero demostrar en una prueba que este repositorio puede encontrar productos que coincidan con varias palabras clave.
A falta de pruebas de integración con un objeto de conexión real, ¿cómo puedo saber que esto en realidad está generando consultas reales y que esas consultas realmente hacen lo que creo que hacen?
Si tengo que burlarme del objeto de conexión en una prueba de unidad, solo puedo probar cosas como "genera la consulta esperada", pero eso no significa que realmente vaya a trabajar . ... es decir, tal vez esté generando la consulta que esperaba, pero tal vez esa consulta no haga lo que creo que hace.
En otras palabras, me parece que una prueba que hace afirmaciones sobre la consulta generada, esencialmente no tiene valor, porque está probando cómo se implementó el método findByKeyword()
, pero eso no prueba que en realidad funciona .
Este problema no se limita a los repositorios o la integración de la base de datos, parece aplicarse en muchos casos, donde hacer afirmaciones sobre el uso de un simulacro (prueba doble) solo prueba cómo se implementan las cosas, no si se implementan. voy a trabajar realmente.
¿Cómo lidias con situaciones como estas?
¿Las pruebas de integración son realmente "malas" en un caso como este?
Entiendo que es mejor probar una cosa, y también entiendo por qué las pruebas de integración conducen a innumerables rutas de código, todas las cuales no se pueden probar, pero en el caso de un servicio (como un repositorio) cuyo El único propósito es interactuar con otro componente, ¿cómo puede realmente probar algo sin pruebas de integración?