Bien, ¡hora de hacer pruebas!
Si has explorado un poco la base de código, te habrás dado cuenta de
que alguien (podría haber sido cualquiera...
pero probablemente un canadiense) coló algunas pruebas en nuestro directorio tests/Functional/.
¿Se han superado?
Ni idea Averigüémoslo
Ve a tu terminal y ejecuta: bin/phpunit Uh-oh, 1 fallo.
Uh-oh, porque, la verdad, ¡soy el simpático canadiense que las añadió
y sé que pasaban al principio del curso!
El fallo está en BookingTest, concretamente, en testCreateBooking: Esperaba un código de estado de redirección
pero obtuvo 500 en la línea 38 de BookingTest.
Ahí es donde enviamos el correo electrónico...
así que si buscamos a alguien a quien culpar, creo que deberíamos empezar por el canadiense, ejem,
yo y mis alocadas maneras de enviar correos electrónicos.
Abre BookingTest.php.
Si has escrito pruebas funcionales con Symfony antes, esto puede parecer un poco diferente
porque estoy utilizando algunas bibliotecas de ayuda.
zenstruck/foundry nos da este rasgo ResetDatabase que limpia la base de datos antes de cada prueba.
También nos proporciona este rasgo Factories que nos permite crear fijaciones de base de datos en nuestras pruebas.
Y HasBrowser es de otro paquete - zenstruck/browser -
y es esencialmente una envoltura fácil de usar alrededor del cliente de pruebas de Symfony.
testCreateBooking es la prueba real.
En primer lugar, creamos un Trip en la base de datos con estos valores conocidos.
A continuación, algunas preaserciones para asegurarnos de que no hay reservas ni clientes en la base de datos.
Ahora, utilizamos ->browser() para navegar a la página de un viaje, rellenar el formulario de reserva y enviarlo.
A continuación, afirmamos que se nos redirige a una URL de reserva específica y comprobamos
que la página contiene algún HTML esperado.
Por último, utilizamos Foundry para hacer algunas afirmaciones sobre los datos de nuestra base de datos.
La línea 38 causó el fallo...
estamos obteniendo un código de respuesta 500 al redirigir a esta página de reserva.
los códigos de estado 500 en las pruebas pueden ser frustrantes porque puede ser difícil
localizar la excepción real.
Por suerte, Browser nos permite lanzar la excepción real.
Al principio de esta cadena, añade ->throwExceptions(): De nuevo en el terminal,
vuelve a ejecutar las pruebas: Ahora vemos una excepción No se puede encontrar la plantilla "@images/mars.png".
Si recuerdas, esto se parece a cómo estamos incrustando las imágenes del viaje en nuestro correo electrónico.
Está fallando porque mars.png no existe en public/imgs.
Para simplificar, vamos a ajustar nuestra prueba para utilizar una imagen existente.
Para nuestra fijación aquí, cambia mars por iss, y abajo,
para ->visit(): /trip/iss: ¡Ejecuta de nuevo las pruebas!
¡Pasa! Parece que nuestro correo electrónico se envía...
¡pero confirmémoslo!
Al final de esta prueba, quiero hacer algunas afirmaciones sobre el correo electrónico.
Symfony lo permite, pero a mí me gusta utilizar una biblioteca
que devuelve la diversión a las pruebas funcionales de correo electrónico.
En tu terminal, ejecuta: composer require
--dev zenstruck/mailer-test Instalado y configurado...
de nuevo en nuestra prueba, habilítala añadiendo el rasgo InteractsWithMailer: Empieza de forma sencilla,
al final de la prueba, escribe $this->mailer()->assertSentEmailCount(1);:
Nota rápida: .env.local -donde ponemos nuestras credenciales Mailtrap reales- no se lee
ni se utiliza en el entorno test: nuestras pruebas sólo cargan .env y este archivo .env.test.
Y en .env, MAILER_DSN se establece en null://null.
¡Estupendo!
Queremos que nuestras pruebas sean rápidas, y que no envíen realmente correos electrónicos.
¡Vuelve a ejecutarlas!
Pasa: ¡se envía 1 correo electrónico!
Vuelve atrás y añade otra aserción: ->assertEmailSentTo().
¿Qué dirección de correo esperamos?
La que rellenamos en el formulario: bruce@wayne-enterprises.com.
Cópiala y pégala.
El segundo argumento es el asunto: Booking Confirmation for Visit Mars: ¡Ejecuta las pruebas!
¡Sigue pasando!
Y fíjate que ahora tenemos 20 afirmaciones en lugar de 19.
¡Pero podemos ir más allá!
En lugar de una cadena para el asunto en esta aserción, utiliza un cierre con TestEmail $email
como argumento: Dentro, ahora podemos hacer muchas más afirmaciones sobre este correo electrónico.
Como ya no vamos a comprobar el asunto, añade primero ésta:
$email->assertSubject('Booking Confirmation for Visit Mars'): ¡Y podemos encadenar más afirmaciones!
Escribe ->assert para ver qué sugiere nuestro editor.
Míralas todas...
Fíjate en assertTextContains y assertHtmlContains.
Puedes hacer una aserción sobre cada uno de ellos por separado, pero, como es una buena práctica que ambos
contengan los detalles importantes, utiliza assertContains() para comprobar los dos a la vez.
Comprueba Visit Mars: Es importante comprobar los enlaces,
así que asegúrate de que está la URL de reserva: ->assertContains('/booking/'..
Ahora, BookingFactory::first()->getUid(): esto busca la primera entidad Booking
en la base de datos (que sabemos por lo anterior que sólo hay una), y obtiene su uid.
Incluso podemos comprobar el archivo adjunto: ->assertHasFile('Terms of Service.pdf'):
Puedes comprobar el tipo de contenido y el contenido del archivo mediante argumentos adicionales, pero por ahora me basta con comprobar
que el archivo adjunto existe.
¡Vamos, pruebas, vamos!
Genial, ¡ya tenemos 25 aserciones!
Una última cosa: si alguna vez tienes problemas para averiguar por qué no pasa una
de estas aserciones de correo electrónico, encadena un ->dd(): y ejecuta tus pruebas.
Cuando llegue a ese dd(), vuelca el correo electrónico para ayudarte a depurar.
¡No olvides eliminarlo cuando hayas terminado!
A continuación, quiero añadir un segundo correo electrónico a nuestra aplicación.
Para evitar la duplicación y mantener la coherencia,
crearemos un diseño de correo electrónico Twig que ambos compartan.