Escritura de pruebas unitarias con PHPUnit, Parte 1: La configuración

Last updated Nov 26, 2022

Contenido

Pruebas unitarias con PHPUnit, Parte 1: La configuración

A principios de este mes, comenzamos a considerar la instalación de PHPUnit en Visual Studio Code con el objetivo final de aprender a escribir pruebas unitarias para nuestros proyectos basados en WordPress.

Con ese fin, esta publicación asume que ha leído las siguientes publicaciones y asume que se ha puesto al día con un puñado de publicaciones anteriores:

Y, por supuesto, instalar PHPUnit en Visual Studio Code como se vincula anteriormente. Una vez hecho esto, estaremos listos para continuar. Pero una cosa a tener en cuenta es que esta noche será un curso tradicional o completo sobre cómo escribir pruebas unitarias.

En cambio, se trata de escribir pruebas unitarias para proyectos de WordPress.

Pruebas unitarias con PHPUnit, Parte 1: La configuración

Antes de profundizar demasiado en esto, quiero dejar en claro que esta no es tanto una publicación sobre desarrollo basado en pruebas, sino una publicación que sienta las bases para comprender la escritura de pruebas unitarias. Y luego, en última instancia, trabajaremos para escribir pruebas unitarias para nuestro código.

Para aquellos de ustedes que hayan leído antes sobre pruebas unitarias, entonces saben que escribir pruebas unitarias es un tema sobre el cual hay mucha información y esta publicación no intentará cubrir todo eso. En cambio, tomará un enfoque más pragmático para escribir pruebas unitarias contra complementos, aplicaciones web y similares basados en WordPress.

1 Escritura de pruebas unitarias

Cada vez que comience a escribir pruebas unitarias por primera vez, se le presentará la idea de los métodos de configuración y eliminación. Esto es común en PHPUnit (al igual que con otros marcos de prueba). Hay algunas cosas sobre estos dos métodos particulares que a menudo causan problemas.

En resumen, las personas tratan las funciones de la siguiente manera:

setUp es como el constructor en el que crea una instancia de su clase y luego prepara todo lo que necesita para su prueba, incluido el objeto que se probará, los datos que se necesitan, etc.
tearDown es el destructor donde reinicias todo y luego te deshaces de tus objetos. Esto suele ser más común en lenguajes compilados, pero tampoco se puede perder dentro de PHPUnit.

Y aunque puedo entender esto completamente, no siempre es así. Estoy hablando por experiencia aquí, también. En cambio, aquí es de donde proviene la prueba de unidad de frase real. Se trata de probar el código de las unidades y hacerlo de una manera limpia y concisa.

Entonces, ¿para qué son estos métodos, de todos modos? Este puede ser un hábito especialmente difícil de romper o incluso un modelo conceptual de romper cuando te estás metiendo en el proceso por primera vez. Con ese fin, quiero examinar el propósito de cada método y luego cómo abordarlo cuando se trabaja con proyectos basados en WordPress.

Y, como de costumbre, trataré de mantener esto lo más simple y pragmático posible. Estoy mucho menos interesado en la teoría detrás de ciertas cosas que en cómo puede servir tanto a mi negocio como a mis proyectos. (Esto no es para descartar la teoría, por supuesto, pero hay un momento y no un lugar para eso y este blog no lo es).

2 La función de configuración

Aunque estoy comenzando con una breve discusión sobre el método setUp, es importante tener en cuenta que su función hermana (como algunos la consideran) no siempre es necesaria.

Por ejemplo, si está escribiendo código donde todo lo que está haciendo es instanciar un objeto o un conjunto de objetos, es posible que el método tearDown no sea necesario. Voy a entrar en más detalles sobre esto en la siguiente sección.

Dicho esto, digamos que tiene una clase que es responsable de ejecutar un poco de lógica de dominio. Recuerde, para los fines de esta publicación, no nos preocupamos por el código que hará las cosas que WordPress hace de forma natural y que ya tiene su propio conjunto de pruebas.

Con eso quiero decir que nos preocupa el código que funciona específicamente dentro de un dominio problemático. Por ejemplo, tal vez nos preocupe escribir una clase que almacene datos en la base de datos. Una de las piezas de información que es responsable de almacenar información en caché es cuánto tiempo se deben almacenar en caché. Por lo tanto, un candidato para la prueba unitaria haría uso de que podemos establecer y cambiar la cantidad de tiempo, ¿verdad?

Por supuesto, tal vez estos datos estén codificados de forma rígida, pero a los efectos del ejemplo, supongamos lo contrario. Esto implica lo siguiente:

Tenemos una clase que sirve como nuestro caché,
La clase mantiene una parte de los datos de la instancia durante cuánto tiempo se debe configurar el caché,
El tiempo de caché se puede configurar desde clases de terceros,
El tiempo de caché se puede leer de clases de terceros.

Esto significa que una prueba unitaria incluiría:

Preparando la clase,
Definición de un valor,
Afirmando que el valor que se definió es el esperado,,
Cambiando el valor,
Afirmar que se actualizó el valor que se cambió.

Entonces, la clase básica puede verse así (toda la documentación se deja fuera de la clase con el fin de mantener el código lo más conciso posible):

Tenga en cuenta que, de forma predeterminada, tenemos el tiempo de caché establecido en 12 horas (en segundos). La clase también admite la capacidad de cambiar y leer la duración.

Esto significa que podemos escribir pruebas que prueben:

si el valor inicial es el esperado,
si el nuevo valor es el esperado (y que sobrescribe el valor inicial)

Una de las cosas que me gustaría señalar en el código anterior es que puede leer que cada prueba debe tener una sola afirmación, mientras que testNewDuration claramente tiene dos afirmaciones.

Tiendo a tomar la idea de una afirmación por prueba como regla general. Por ejemplo, en este caso, quiero afirmar que el valor inicial se sobrescribe o no se almacena en ningún lugar y se almacena el nuevo valor.

Sin embargo, es posible que este no sea siempre el caso, por lo que es posible que deba tratar este tipo de situaciones con cuidado.

Como puedes ver, esto no tiene nada que ver con WordPress; sin embargo, tiene que ver con la lógica de prueba relacionada específicamente con el dominio en cuestión. A saber, la duración del caché. Y esto es de lo que se trata el núcleo de las pruebas unitarias: probar el comportamiento lógico de las unidades de código para asegurarnos de que todo funcione como se espera.

Y dependiendo de cuándo escriba este código, es posible que tenga pruebas fallidas. En última instancia, esto puede ayudar con el diseño de la clase, pero ese es otro tema y no forma parte de esta publicación.

Ejecutando las pruebas

Una vez que se escriben las pruebas, es importante poder ejecutarlas para ver si pasan, si fallan, qué pasa y qué no. Pero aún no hemos terminado. Quiero brindar una visión integral de las pruebas unitarias en el contexto de WordPress y esto se trata de discutir qué ofrece WordPress, qué no, algunos conceptos erróneos y cómo ejecutar estas pruebas en la terminal o dentro de Visual Studio Code.

En la próxima publicación de esta serie, veremos la función tearDown y cómo (y cuándo) usarla, cuándo se necesita, cuándo no, y luego veremos un poco alrededor de la unidad. pruebas en WordPress en general.

En última instancia, estamos trabajando para obtener una imagen completa de cómo hacer esto y cómo hacerlo bien. Pero es importante sentar las bases para eso y hacerlo en el lapso de unas pocas publicaciones es más fácil que en una publicación monolítica.

Así que examinar tearDown(), su uso y cómo ejecutar pruebas desde la línea de comandos será el tema de la próxima publicación de esta serie.

Fuente de grabación: tommcfarlin.com