Una introducción a las pruebas automatizadas de complementos de WordPress con PHPUnit

Publicado: 2022-03-10

Resumen rápido ↬ Realmente no quiere pasar horas probando manualmente cada parte de su complemento de WordPress para asegurarse de que nada se rompa cada vez que implementa una nueva versión, ¿verdad? En este tutorial, aprenderá cómo realizar pruebas de manera eficiente con pruebas automatizadas.

WordPress es un sistema de administración de contenido popular para crear sitios web porque es fácil comenzar con él y hay una tonelada de temas y complementos disponibles para ampliar su conjunto de funciones. La razón principal por la que WordPress tiene muchos complementos y temas es porque es fácil para los desarrolladores de cualquier nivel comenzar a crear uno. La mayoría de sus desarrolladores no tienen experiencia y no escriben pruebas para su trabajo, quizás por las siguientes razones:

No hay muchas discusiones sobre las pruebas unitarias, por lo que es posible que no sepan que las pruebas son posibles.
No creen en el valor de escribir pruebas para su código, o creen que los ralentizará.
Creen que probar para ver si su complemento o tema funciona en el navegador es suficiente.

En este tutorial, aprenderemos qué son las pruebas automatizadas y su importancia, conoceremos PHPUnit y WP-CLI, aprenderemos a escribir una prueba y, finalmente, configuraremos pruebas automatizadas continuas con Travis CI.

Optamos por usar Travis CI porque ofrece una integración perfecta con GitHub; no tiene que ir a su repositorio y configurar ninguna conexión entre ellos. Y es gratis para repositorios públicos. A diferencia de sus competidores, como Semaphore CI, GitLab CI y CircleCI, Travis CI no ofrece un plan de repositorio privado gratuito. Sin embargo, ninguno de sus competidores ofrece una integración perfecta con GitHub como lo hace.

¿Qué son las pruebas automatizadas?

Según Wikipedia, las pruebas automatizadas o la automatización de pruebas es el uso de un software especial (separado del software que se está probando) para controlar la ejecución de las pruebas y la comparación de los resultados reales con los resultados previstos. La automatización de pruebas puede automatizar algunas tareas repetitivas pero necesarias en un proceso de prueba formalizado que ya existe, o realizar pruebas adicionales que serían difíciles de realizar manualmente.

¡Más después del salto! Continúe leyendo a continuación ↓

Hay varios tipos de pruebas. De todos, las pruebas unitarias son las más populares. Las pruebas unitarias verifican que un bloque de código, función o método de clase hace lo que se supone que debe hacer. Haremos pruebas unitarias en este tutorial.

Las pruebas automatizadas ayudan a detectar errores para que no lleguen a producción. Sin duda, un complemento codificado y probado tardaría más en completarse que uno que no se haya probado. Sin embargo, el complemento resultante contendría menos o ningún error.

Veamos un ejemplo simple del mundo real de cómo las pruebas unitarias son invaluables y para qué podemos usarlas.

Mi complemento de generación de prospectos de WordPress tiene una clase OptinThemesRepository , con un método add() para agregar nuevas plantillas de formulario de suscripción y un método get() para recuperar una plantilla de formulario de suscripción.

Para garantizar que tanto add() como get() funcionen según lo previsto ahora y en el futuro, escribí la prueba a continuación.

 public function testAddGetMethods() { $kick_optin_form = array( 'name' => 'Kick', 'optin_class' => 'kick', 'optin_type' => 'kick', 'screenshot' => MAILOPTIN_ASSETS_URL . 'img/kick.png' ); // add kick optin theme OptinThemesRepository::add($kick_optin_form); $result = OptinThemesRepository::get('kick'); $this->assertEquals($kick_optin_form, $result); }

Si, en el futuro, esta prueba comenzara a fallar, sabría que hay un problema y sabría la función exacta, el método de clase o el lugar en mi complemento donde está ocurriendo.

Beneficios de las pruebas automatizadas

Ahora que sabemos qué son las pruebas automatizadas, veamos más beneficios.

Detección temprana de errores

Mientras desarrolla software, puede encontrar fácilmente errores con herramientas de prueba automatizadas. Esto puede ahorrar mucho tiempo y esfuerzo en el seguimiento de errores.

Mayor calidad de software

Un probador con muchos años de experiencia puede cometer errores cuando tiene que preparar los mismos guiones de prueba manuales aburridos una y otra vez. Las pruebas automatizadas no solo arrojan resultados precisos, sino que también ahorran tiempo.

Informes fáciles y robustos

Las herramientas de prueba automatizadas pueden rastrear todos y cada uno de los scripts de prueba. La ejecución de cada script de prueba se puede ver en registros visuales. El registro visual, o informe, generalmente muestra la cantidad de scripts de prueba ejecutados y su estado (por ejemplo, aprobado, fallido u omitido), los errores informados y sugerencias sobre cómo corregir los errores.

Antes de repasar cómo configurar y escribir pruebas, creemos un complemento simple para usar como estudio de caso.

Construyendo un complemento de WordPress

Vamos a crear un complemento simple que muestre las metaetiquetas de verificación de webmaster de Google y Bing en el encabezado de la interfaz de WordPress. El complemento está alojado en mi cuenta de GitHub.

El código para este complemento a continuación irá en el archivo wp-meta-verify.php .

 <?php class WP_Meta_Verify { public function __construct() { add_action('wp_head', \[$this, 'header_code']); } public function header_code() { $google_code = get_option('wpmv_google_code'); $bing_code = get_option('wpmv_google_code'); echo $this->google_site_verification($google_code); echo $this->bing_site_verification($bing_code); } public function google_site_verification($code) { return "<meta name=\"google-site-verification\" content=\"$code\">"; } public function bing_site_verification($code) { return "<meta name=\"msvalidate.01\" content=\"$code\">"; } } new WP_Meta_Verify();

Puede notar que no incluimos una página de configuración en el complemento, donde normalmente guardaría el código de verificación de Google y Bing. Hice esto a propósito para mantener esto simple y centrar nuestra atención en lo que más importa. Sin embargo, get_option('wpmv_google_code') y get_option('wpmv_bing_code') asumen que hay una página de configuración y recuperan los códigos de verificación desde allí.

Unidad de prueba de un complemento de WordPress

PHPUnit es la herramienta de prueba de facto para PHP, mientras que WP-CLI es la interfaz de línea de comandos oficial para WordPress.

Antes de WP-CLI, configurar las pruebas de PHPUnit para los complementos de WordPress era una molestia. WP-CLI tiene una excelente guía para configurarlo; sin embargo, seguiremos repasando los pasos aquí.

Instalar PHPUnit

Para instalar PHPUnit, ejecute los siguientes comandos.

 composer global require phpunit/phpunit:5.*

Nota: estamos instalando explícitamente 5.x porque eso es lo que admite WordPress cuando ejecuta PHP 7 o superior, que tengo en mi máquina. Instale PHPUnit 4.8 si está ejecutando PHP versión 5.

Ejecute phpunit --version para confirmar que se ha instalado.

Instalar WP-CLI

Para instalar WP-CLI, ejecute los siguientes comandos.

 curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar chmod +x wp-cli.phar sudo mv wp-cli.phar /usr/local/bin/wp

Ejecute wp --info para confirmar su instalación.

Habiendo instalado PHPUnit y WP-CLI, usaremos este último para configurar la prueba de unidad para el complemento.

Configurar prueba de unidad de complemento

Cambie el directorio de su terminal a la raíz de su instalación de WordPress y ejecute el siguiente comando para generar los archivos de prueba del complemento.

 wp scaffold plugin-tests wp-meta-verify

A continuación se muestra cómo se verá la estructura del complemento después de que el comando anterior genere los archivos de prueba.

 |-bin/ |----install-wp-tests.sh |-tests/ |----bootstrap.php |----test-sample.php |-.travis.yml |-phpcs.xml.dist |-phpunit.xml.dist |-wp-meta-verify.php

Nota: De manera predeterminada, el comando wp scaffold plugin-tests genera un archivo de configuración de Travis CI. Puede especificar un indicador --ci para generar un archivo de configuración para el servicio de CI que utiliza, así: wp scaffold plugin-tests --c gitlab . En el momento de escribir este artículo, solo se admiten Travis CI, CircleCI y GitLab CI.

Cambie el directorio de su terminal al directorio de su complemento y ejecute el script de instalación:

 cd path-to-wordpress-plugin

 bin/install-wp-tests.sh wordpress_test root '' localhost latest

Si eres como yo, entonces tu nombre de usuario de MySQL no es root y la contraseña no está vacía. Por ejemplo, suponga que el nombre de usuario es homestead y la contraseña es secret . Ejecutarías el script de instalación así:

 bin/install-wp-tests.sh wordpress_test homestead 'secret' localhost latest

Ejecute el comando phpunit para ejecutar la prueba predeterminada en tests/test-sample.php .

Resultado de la prueba PHPUnit — Resultado de la prueba de PHPUnit (vista previa grande)

Escriba nuestras pruebas de complementos

Cree un archivo test-wp-meta-verify.php en la carpeta de tests . Contendrá nuestras pruebas de complemento con la siguiente clase de setUp .

 <?php class WP_Meta_VerifyTest extends WP_UnitTestCase { public function setUp() { parent::setUp(); $this->class_instance = new WP_Meta_Verify(); } public function test_google_site_verification() { } public function test_bing_site_verification() { } }

Vale la pena señalar que para que un método se considere una prueba unitaria, debe tener el prefijo test . Una mejor práctica es agregar un sufijo Test a cada clase de prueba, aunque no es obligatorio. Ver WP_Meta_VerifyTest .

¿Confundido acerca de lo que hace setUp() ? Solo sepa que PHPUnit lo ejecuta una vez antes de cada método de prueba (y en instancias nuevas) de la clase de caso de prueba. También existe tearDown() , pero se ejecuta después de cada método de prueba. También existen setUpBeforeClass() y tearDownAfterClass() , que se ejecutan antes y después de cada caso de prueba, respectivamente. Un caso de prueba es básicamente una clase que contiene varios métodos de prueba. Consulte el manual de WordPress y la documentación de PHPUnit para obtener más información.

De la clase anterior, es bastante obvio que vamos a escribir pruebas para los métodos google_site_verification y bing_site_verification de nuestra clase de complemento.

 public function test_google_site_verification() { $meta_tag = $this->class_instance->google_site_verification('B6wFaCRbzWE42SyxSvKUOyyPxZfJCb5g'); $expected = '<meta name="google-site-verification" content="B6wFaCRbzWE42SyxSvKUOyyPxZfJCb5g">'; $this->assertEquals($expected, $meta_tag); }

 public function test_bing_site_verification() { $meta_tag = $this->class_instance->bing_site_verification('B6wFaCRbzWE42SyxSvKUOyyPxZfJCb5g'); $expected = '<meta name="msvalidate.01" content="B6wFaCRbzWE42SyxSvKUOyyPxZfJCb5g">'; $this->assertEquals($expected, $meta_tag); }

Básicamente, las pruebas garantizarán que ambos métodos devuelvan la metaetiqueta correcta cuando se les pasen como argumentos los códigos de verificación de webmaster de Google y Bing.

Ejecute phpunit y debería ver un resultado similar a la captura de pantalla a continuación.

Pruebas automatizadas continuas con Travis CI

Travis CI es un servicio de integración continua alojado y distribuido que se utiliza para crear y probar proyectos de software alojados en GitHub.

Para usar Travis CI, por lo tanto, tenemos que publicar nuestro complemento en GitHub. Adelante, hazlo ahora. Siéntete libre de referirte a la mía.

Gracias a WP-CLI, ya lo tenemos configurado en nuestro complemento, cortesía del archivo .travis.yml .

Me gustaría mencionar que no me adhiero a los estándares de codificación de WordPress, sino a las recomendaciones de estándares de PHP, y mis complementos requieren al menos PHP 5.4. Para que mis compilaciones no fallaran, tuve que reemplazar su matriz con lo siguiente en el archivo .travis.yml .

 matrix: include: - php: 7.1 env: WP_VERSION=latest - php: 7.0 env: WP_VERSION=latest - php: 5.6 env: WP_VERSION=latest - php: 5.6 env: WP_VERSION=trunk - php: 5.5 env: WP_VERSION=latest - php: 5.4 env: WP_VERSION=latest

Dirígete a Travis CI e inicia sesión con tu cuenta de GitHub. Siga la guía en pantalla para agregar su repositorio de GitHub.

Después de la sincronización de la cuenta con GitHub, desplácese hasta el repositorio de su complemento y actívelo.

Configuración del repositorio de Travis CI (vista previa grande)

La próxima vez que realice un cambio de código y presione GitHub, se activará una compilación en Travis CI.

Resultado de compilación de Travis CI (vista previa grande)

He puesto a su disposición un resultado de compilación exitoso para su placer visual.

Terminando

No es ningún secreto que muchos desarrolladores, no solo los de WordPress, no escriben pruebas para sus proyectos porque no los conocen. Incluso algunos de los experimentados y avanzados entre nosotros aparentemente no lo hacen porque lo consideran una pérdida de tiempo.

Por supuesto, configurar pruebas automatizadas puede ser aburrido y llevar mucho tiempo. Sin embargo, es una inversión que garantizará que se introduzcan pocos o ningún error en su software, lo que le ahorrará el tiempo y los recursos (incluidos los financieros) que los errores en su software le habrían costado.

Siempre escriba una prueba antes de implementar una función, para que no se olvide o se sienta perezoso para hacerlo después de que se haya implementado la función.

Espero que ahora reconozca la importancia de escribir pruebas y cómo comenzar a escribir una para su propio complemento de WordPress.

Si tiene alguna pregunta o comentario, hágamelo saber en la sección de comentarios.