He probado mi clase de unidad, ahora ¿cómo empiezo con una prueba de integración?

He escrito una clase que administra destinatarios en una lista de MailChimp, llamada MailChimpRecipient. Utiliza la clase MCAPI, que es un contenedor de API de terceros.

http://apidocs.mailchimp.com/api/1.3/ http://apidocs.mailchimp.com/api/downloads/

Paso el objeto MCAPI al constructor del objeto MailChimpRecipient, así que escribí pruebas unitarias usando PHPUnit que prueban toda la lógica en mi propia clase (no estoy probando la clase MCAPI). Tengo una cobertura de código del 100% y todas las pruebas pasan. Esto se hace burlándose y tropezando con el objeto MCAPI.

Mi siguiente paso fue escribir una prueba de integración, también usando PHPUnit, donde construiría el accesorio MailChimpRecipient usando un objeto MCAPI real, configurado para usar una lista real de MailChimp.

He escrito lo que creo que es una prueba de integración, que básicamente ejecuta pruebas contra la interfaz pública del objeto, como:

public function testAddedRecipientCanBeFound()
{
    $emailAddress = 'fred@fredsdomain.com';
    $forename = 'Fred';
    $surname = 'Smith';

    // First, delete the email address if it is already on the list
    $oldRecipient = $this->createRecipient();
    if($oldRecipient->find($emailAddress))
    {
        $oldRecipient->delete();
    }
    unset($oldRecipient);

    // Add the recipient using the test data
    $newRecipient = $this->createRecipient();
    $newRecipient->setForename($forename);
    $newRecipient->setSurname($surname);
    $newRecipient->setEmailAddress($emailAddress);
    $newRecipient->add();
    unset($newRecipient);

    // Assert that the recipient can be found using the same email address
    $this->assertTrue($this->_recipient->find($emailAddress));
}

La prueba de "integración" no prueba ninguno de los elementos internos de la clase, solo se asegura de que, dado un objeto MCAPI real, se comporte como se anuncia.

¿Es esto correcto? ¿Es esta la mejor manera de ejecutar una prueba de interposición? Después de todo, las partes internas han sido probadas con una prueba unitaria. ¿Estoy en lo cierto al pensar que la prueba de integración está ahí para probar que realmente funciona, de acuerdo con la forma en que se anuncia su comportamiento?

Para ir un paso más allá, la clase MailChimpRecipient implementa una interfaz, que también será implementada por otras clases. La idea es usar una fábrica para pasar diferentes tipos de objetos de destinatario de la lista de correo a mi código, que hacen lo mismo, aunque usan diferentes proveedores de listas de correo. Dado que mis pruebas de integración prueban esa interfaz, ¿qué tal si la usamos para todas las clases que implementan la interfaz? Luego, en el futuro, si diseño una nueva clase para ser utilizada de manera intercambiable, puedo ejecutar la misma prueba de integración antes de insertarla en un proyecto.

¿Suena esto razonable? Las pruebas unitarias prueban las partes internas de un objeto, las pruebas de integración aseguran que se comporte como se anuncia.

Al probar su código, debe prestar atención a tres áreas:

• Prueba de escenario
• Prueba funcional
• Examen de la unidad

Normalmente, la cantidad de pruebas que tiene en cada categoría tendría la forma de una pirámide, es decir, muchas pruebas unitarias en la parte inferior, algunas pruebas funcionales en el medio y solo unas pocas pruebas de escenarios.

Con una prueba unitaria, se burla de todo lo que usa la clase bajo prueba y la prueba de forma aislada (es por eso que es importante asegurarse de que dentro de su clase recupere todas las dependencias a través de la inyección para que puedan reemplazarse bajo prueba).

Con las pruebas unitarias, usted prueba todas las posibilidades, por lo que no solo la 'ruta feliz' sino también todas las condiciones de error.

Si está completamente seguro de que todas sus unidades funcionan de manera aislada, escriba un par de pruebas (pruebas funcionales) para asegurarse de que las unidades también funcionen cuando se combinen. Luego, escribe una prueba de escenario, que prueba el cableado entre todos los módulos funcionales.

Por ejemplo, suponga que está probando un automóvil.

Puede ensamblar todo el automóvil y, como conductor, verificar todas las condiciones posibles, pero eso sería realmente difícil de hacer.

En su lugar, probaría una pequeña parte del motor con todas las posibilidades (prueba unitaria)

Luego prueba todo el motor (separado del automóvil), lo que sería una prueba funcional.

Como última prueba, ingresa su llave, enciende el automóvil y lo conduce al estacionamiento. Si eso funciona, entonces sabe que todas las partes (batería, combustible, motor, ...) están conectadas y, dado que las probó de forma aislada, puede estar bastante seguro de que todo el automóvil funciona correctamente.

Entonces, en su caso, probó todas las condiciones de error y el camino feliz en la prueba de su unidad y sabe que solo tiene que hacer una prueba de extremo a extremo con los 'componentes reales' para verificar si el cableado es correcto.

Algunos otros puntos,

• Evite la lógica condicional en su prueba unitaria. Si tiene que limpiar, está utilizando algún tipo de estado global y las pruebas pueden influirse repentinamente entre sí.
• No especifique ningún dato que no sea relevante para la prueba. Si cambiara el nombre o el apellido, ¿fallaría la prueba? Probablemente no porque sea la dirección de correo electrónico lo importante, sino porque lo mencionas explícitamente en tu prueba, no puedo estar seguro. Intente mirar el Patrón de construcción para construir sus datos de prueba y hacer explícito lo que es realmente importante.