Escritura de pruebas unitarias con PHPUnit, parte 2: el derribo

A fines del mes pasado, comencé a hablar sobre escribir pruebas unitarias en PHPUnit para código basado en WordPress. Esto incluía principalmente la idea de configurar PHPUnit, la función de configuración y escribir pruebas básicas.

Sin embargo, esto no discutió lo que sé sobre la función tearDown, que sigue siendo una característica importante de escribir usando pruebas. Además, también hay dos formas de considerar escribir pruebas para proyectos de WordPress.

A saber:

1. escribir pruebas específicamente para complementos y funcionalidad de capa de aplicación,
2. ejecutando pruebas unitarias contra la aplicación de WordPress.

Sin embargo, antes de continuar con esta publicación en particular, recomiendo ponerse al día con lo que he cubierto hasta ahora. Esto incluye las siguientes publicaciones:

1. Un entorno de desarrollo de WordPress (usando un administrador de paquetes)
2. Un IDE para el desarrollo de WordPress
3. Trabajar con la configuración de usuario en Visual Studio Code
4. Escritura de pruebas unitarias con PHPUnit, Parte 1: La configuración

Una vez que haya hecho eso, regrese a esta publicación y continuemos discutiendo la función tearDown y cómo se ven realmente las pruebas unitarias en el contexto de WordPress.

Pruebas unitarias con PHPUnit, Parte 2: El derribo

Antes de continuar, recuerde que los desarrolladores a menudo tratan la función de instalación como el constructor y la función de desmontaje como un destructor; sin embargo, recuerde que esto último no siempre es necesario.

Aquí hay una buena regla general para recordar:

• Cualquier cosa que necesite una función de prueba llamará a la función setUp para que se necesiten las clases necesarias.
• La función tearDown no siempre es necesaria ya que la función setUp puede reinicializar una clase.

Entonces, ¿qué significa esto para la función tearDown si no restablece los datos que se crean durante la función de configuración?

1 La función de desmontaje

El mejor consejo que puedo dar sobre la función tearDown es que debe usarse si se configura algo durante una de las pruebas que se quedan atrás.

Esto podría ser algo que se escribe en una base de datos, algo que se escribe en un registro o, de manera más general, algo que se escribe en el disco duro.

Por lo tanto, si una prueba escribe un registro o un archivo, el método tearDown se ejecutará después de una prueba y debería eliminar cualquier prueba grabada en la unidad que no sea parte de la prueba pero que no se necesite permanentemente para la próxima prueba o que debe limpiarse después de sí mismo.

Entonces, en cierto sentido, es como un destructor, pero si nunca ha usado un lenguaje que tiene un destructor, esa nomenclatura parece irrelevante o no tiene sentido.

Un destructor es una función miembro especial que se llama cuando finaliza el tiempo de vida de un objeto. El propósito del destructor es liberar los recursos que el objeto haya podido adquirir durante su vida.

Por lo tanto, tal vez sea mejor simplemente pensar en la función como una forma de limpieza después de una prueba (y no en el sentido de establecer una variable igual a nula ya que la función setUp puede hacer eso).

2 pruebas unitarias para proyectos de WordPress

Al escribir pruebas unitarias para proyectos de WordPress, debemos asegurarnos de ser claros sobre el tipo de pruebas unitarias de las que estamos hablando.

Por ejemplo, a lo que me referiré como pruebas unitarias clásicas o estándar siguen la metodología de "desarrollo basado en pruebas" de la que hablaré en un momento. Por otro lado, WordPress tiene su propio conjunto de pruebas unitarias para temas y similares, de los que también hablaré un poco más adelante en esta publicación.

Pero para esta sección, pensé que podría ser útil hablar un poco sobre lo primero en lugar de lo segundo para que pueda ver cómo podría funcionar.

En el siguiente ejemplo, estoy escribiendo pruebas contra un complemento que es responsable de comunicarse con una API de terceros. Este complemento en particular requiere un nombre de usuario y contraseña o una API y queremos asegurarnos de que, para los fines de esta publicación, recupere correctamente un error cada vez que se ejecute la prueba.

Tenga en cuenta que al leer este código, me verá hablar un poco sobre la reflexión. Voy a hacer una publicación completa sobre PHP Reflection pronto para arrojar algo de luz sobre esto.

Sin embargo, para el código a continuación, suponga que es una forma en que podemos obtener acceso a propiedades que de otro modo estarían marcadas como privadas.

Recordemos de la última publicación de esta serie, tuvimos una prueba inicial que se veía así:

Tenga en cuenta, sin embargo, que en esta prueba no hay una función de desmontaje que tenga sentido, ¿verdad? Después de todo, no se escribe nada en una base de datos o en un archivo.

Pero digamos que queremos presentar un caso de prueba que tendrá un nombre de archivo, contenido y escribirá el contenido en el archivo. En este caso, serán datos estáticos, pero técnicamente podrían ser cualquier cosa que esté escrita en el disco.

1 Configuración de la prueba

Primero, queremos configurar la prueba definiendo el nombre del archivo, el contenido del archivo y preparando las propiedades.

Bastante fácil, ¿verdad?

2 Escribir y leer datos

A continuación, queremos escribir los datos, leer los datos y afirmar que los contenidos son los mismos.

En este punto, si ejecuta la prueba (que aún no he cubierto técnicamente sobre cómo hacerlo), notará que testFile.txt aún reside en su sistema.

3 Uso de desmontaje

Finalmente, debemos trabajar con el método tearDown para asegurarnos de que el archivo se elimine al finalizar la prueba unitaria. Así es como puede verse si ha implementado su código como lo que ve arriba.

Tenga en cuenta que en el método tearDown, primero verifico si existe un archivo. Esto se debe a que si simplemente intenta desvincular un archivo que no está presente, obtendrá un error al ejecutar sus pruebas porque si tearDown está presente, intentará eliminar algo después de cada función de prueba. Y si el archivo no existe, entonces no hay nada que eliminar y, por lo tanto, resultará en un problema.

Entonces, en un intento de escribir código a la defensiva, creo que es responsable de verificar si el archivo existe antes de intentar eliminarlo.

3 Orden de Operaciones

Cuando se trata de pruebas unitarias puras, normalmente leerá esto en términos de desarrollo basado en pruebas. Este es un gran tema en sí mismo; sin embargo, vale la pena mencionarlo aquí si opta por investigarlo más e incluso implementarlo en sus esfuerzos de desarrollo.

La idea general detrás de este enfoque a menudo se denomina "repetición rojo-verde". Y no lo niego, hay algo en este enfoque. Es decir, le permite a usted, como desarrollador, escribir código como espera que funcione antes de escribir el código.

La psicología detrás de esto es la siguiente: si sabe cómo funciona el código, es más probable que escriba pruebas que pasen; mientras que, si escribe pruebas sobre cómo debería funcionar el código, debería escribir un mejor código.

Desafortunadamente, no siempre tenemos ese lujo. Pero eso no significa que debamos tirar al proverbial bebé con el agua. En cambio, tengo la mentalidad de que debe escribir pruebas cuando pueda y escribir el código después; de lo contrario, escriba sus pruebas después de su código.

En última instancia, tener pruebas independientemente será mejor que ninguna prueba.

4 Pruebas con WordPress

Cuando se trata de pruebas unitarias en WordPress, hay algunas cosas con las que probablemente te hayas topado. A veces, el contenido es un nombre inapropiado o incluso puede ser engañoso en términos de "pruebas unitarias en WordPress".

Por ejemplo, hay dos cosas que vale la pena señalar:

1. La prueba de unidad temática. Este conjunto particular de contenido está destinado a ayudar a los desarrolladores de temas a probar todos los casos principales y secundarios de sus temas. No hay herramientas automatizadas, por ejemplo, que usaría como en lo que hemos discutido anteriormente.
2. Pruebas automatizadas. WordPress se envía con su propio conjunto de pruebas unitarias para que no tengamos que escribir pruebas contra la mayoría de las funciones de WordPress (como si las funciones de la API funcionan o no como se esperaba). Esto nos permite centrarnos en escribir pruebas unitarias para nuestra propia lógica de dominio.
3. Pruebas unitarias de complementos. Si ha usado WP-CLI (o está interesado en él), probablemente haya leído esta página o incluso haya usado esta herramienta. Es útil, pero también se enfoca en aspectos específicos de la prueba de complementos de WordPress.

Todo lo anterior es información útil, y no digo que deba ser ignorada. En cambio, debe combinarse con el resto de la información utilizada en esta publicación.

Ejecución de pruebas unitarias

En la próxima publicación, lo guiaré a través de todo lo que necesita saber para configurar un archivo XML que informará a PHPUnit sobre dónde residen las pruebas y cómo ejecutarlas.

Sin embargo, por ahora, revise el código que se encuentra en esta publicación y prepárese para desarrollarlo en la próxima publicación de esta serie.