Algunas personas sostienen que las pruebas de integración son malas y están mal : todo debe ser probado por la unidad, lo que significa que debes burlarte de las dependencias; una opción que, por varias razones, no siempre me gusta.
Creo que, en algunos casos, una prueba unitaria 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]);
}
}Digamos que quiero demostrar en una prueba que este repositorio realmente puede encontrar productos que coincidan con varias palabras clave dadas.
A falta de pruebas de integración con un objeto de conexión real, ¿cómo puedo saber que esto realmente 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 unitaria, solo puedo probar cosas como "genera la consulta esperada", pero eso no significa que realmente vaya a funcionar ... es decir, tal vez esté generando la consulta Lo esperaba, pero tal vez esa consulta no hace lo que creo que hace.
En otras palabras, siento que una prueba que hace afirmaciones sobre la consulta generada, esencialmente no tiene valor, porque está probando cómo findByKeyword()se implementó el método , pero eso no prueba que realmente funcione .
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 van a En realidad funciona.
¿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 único propósito es para interactuar con otro componente, ¿cómo puede realmente probar algo sin pruebas de integración?
