Cómo comenzar a probar su código de WordPress con el marco de prueba de Pest PHP

Todos podemos estar de acuerdo en que WordPress ha recorrido un largo camino desde sus inicios y que se convirtió en algo mucho más que un software de blogs.

En esencia, sigue siendo un sistema de administración de contenido (CMS), pero con más de 59 000 complementos en el directorio wordpress.org, puede personalizarlo para que sea mucho más.

La razón de su popularidad es su baja barrera de entrada tanto para los creadores como para los desarrolladores de contenido. A veces esto tiene un costo. No es ningún secreto que WordPress tiene una mala reputación cuando se trata de desarrollo. Tiene una gran cantidad de equipaje heredado y reglas estrictas que evitan cualquier cambio que rompa la compatibilidad con versiones anteriores cuando se trata de código PHP (Gutenberg es otra historia en la que no entraré).

Ese código PHP heredado a menudo lo usan los desarrolladores que están comenzando a ingresar al mundo de la programación, y el problema con eso es que pueden aprender algunos patrones de programación incorrectos. Eso a su vez significa que reutilizarán el código mal escrito, aumentando la cantidad de código incorrecto en el mundo.

Aquí es donde WordPress obtiene su mala reputación en la comunidad de desarrolladores.

rompiendo el ciclo

Entonces, ¿cómo podemos romper este ciclo de código incorrecto? Enseñando a los nuevos desarrolladores cómo deben escribir un buen código. Un ejemplo de cómo enseñar a los nuevos desarrolladores (pero también a los antiguos que todavía se aferran a la forma de hacer las cosas de 'WordPress') es escribir tutoriales.

Otra forma es alentarlos a usar herramientas que puedan ayudarlos a escribir mejor código.

Actualmente estoy involucrado en el trabajo que tiene como objetivo lanzar la nueva versión de los Estándares de codificación de WordPress, un conjunto de reglas utilizadas para la herramienta PHP_CodeSniffer que le permitirá saber si su código tiene algunos problemas potenciales (seguridad, mejores prácticas, estilo de código ).

Otra herramienta que he desarrollado recientemente es un paquete que ayudará a los desarrolladores a configurar pruebas de integración de WordPress que utilizan el marco de pruebas de plagas.

Ok, entonces, ¿por qué necesitamos esta nueva herramienta?

La principal motivación detrás de la creación de este paquete es alentar a más personas a escribir pruebas para su código, especialmente a los desarrolladores de complementos.

Muchos desarrolladores en la comunidad de WordPress siguen el mantra: puedo ver que funciona porque lo probé en mi navegador. Eso está bien, pero hay problemas con eso.

En primer lugar, lleva mucho tiempo. Cada vez que haga algún cambio, debe asegurarse de que funcione, pero también de no romper nada.

En segundo lugar, la gente comete errores. No somos infalibles, y el código puede ser mal utilizado de maneras que nunca creíste posibles. Te sorprendería lo creativas que pueden ser las personas al escribir código.

Las pruebas automatizadas son rápidas y pueden ayudarlo a probar varios casos que ocurrirán cuando ejecute su código.

Usted prueba el comportamiento previsto (ruta feliz) y, de manera rápida, puede agregar ejemplos de cómo se puede usar su código de una manera que no pretendía que se usara (ruta infeliz).

También protege su código de regresiones. Una regresión de código es cuando sin querer rompe una parte de su código al agregar código nuevo.

El problema con las pruebas establecidas hasta ahora

Probar en WordPress no es algo nuevo. Y no es como si no pudieras configurar pruebas para tu código antes. Hay bibliotecas increíbles que te ayudarán a configurar todo como wp-browser.

Pero el problema es que el procedimiento de configuración suele ser complicado.

Debe configurar una base de datos separada para las pruebas, y debe ejecutar ciertos scripts, luego cambiar los archivos para que todo funcione.

Seamos realistas, no es algo fácil de hacer, y los desarrolladores son criaturas perezosas por naturaleza (es por eso que escribimos código para que haga las cosas por nosotros).

El objetivo de la configuración de la prueba de integración de wp-pest es eliminar todo ese trabajo adicional.

Cómo configurarlo

Para configurarlo, su proyecto debe usar Composer. Es una forma estándar de facto de agregar paquetes a su código.

En tu tipo de terminal

 composer require dingo-d/wp-pest-integration-test-setup --dev

Una vez que haya descargado el paquete y sus dependencias, puede configurar las pruebas de tema escribiendo

 vendor/bin/wp-pest setup theme

O, en el caso de que desee configurar pruebas para su complemento, puede escribir

 vendor/bin/wp-pest setup plugin --plugin-slug=your-plugin-slug

Opcionalmente, puede proporcionar un parámetro --wp-version para especificar en qué versión de WordPress le gustaría probar su código.

En segundo plano, se descargará una instancia de WordPress y se configurará una base de datos en memoria, junto con dos ejemplos de pruebas que puede ejecutar.

Entonces, ejecutando cualquiera

 vendor/bin/pest --group=unit

o

 vendor/bin/pest --group=integration

ejecutará las pruebas.

La belleza de Pest es que su sintaxis es amigable para los desarrolladores. Tiene una documentación increíble y una gran sintaxis. Veamos un ejemplo sencillo. Digamos que está registrando un tipo de publicación personalizada llamada 'Libros':

 <?php /** * Plugin Name: Test plugin * Desctiption: Test plugin * Version: 1.0.0 * License: MIT */ function test_plugin_register_books_cpt() { $args = array( 'label' => esc_html__( 'Books', 'test-plugin' ), 'public' => true, 'publicly_queryable' => true, 'show_ui' => true, 'show_in_menu' => true, 'query_var' => true, 'rewrite' => array( 'slug' => 'book' ), 'capability_type' => 'post', 'has_archive' => true, 'hierarchical' => false, 'menu_position' => null, 'supports' => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' ), ); register_post_type( 'book', $args ); } add_action( 'init', 'test_plugin_register_books_cpt' );

Después de ejecutar el comando de configuración que agrega un ejemplo, una prueba llamada BooksCptTest.php se vería así:

 <?php namespace Tests\Integration; beforeEach(function () { parent::setUp(); }); afterEach(function () { parent::tearDown(); }); test('Books custom post type is registered', function () { // We can use assertions from PHP_Unit. $this->assertNotFalse(has_action('init', 'test_plugin_register_books_cpt')); $registeredPostTypes = \get_post_types(); // Or we can use expectations API from Pest. expect($registeredPostTypes) ->toBeArray() ->toHaveKey('book'); });

La ejecución vendor/bin/pest --group=integration nos da el siguiente resultado:

 Installing... Running as single site... To run multisite, use -c tests/phpunit/multisite.xml Not running ajax tests. To execute these, use --group ajax. Not running ms-files tests. To execute these, use --group ms-files. Not running external-http tests. To execute these, use --group external-http. PASS Tests\\Integration\\BooksCptTest ✓ Books custom post type is registered Tests: 1 passed Time: 0.14s

Conclusión

Y así, tiene la capacidad de ejecutar pruebas de integración de WordPress en su tema o complemento. Las pruebas son increíbles porque no solo nos protegen de los errores, sino que también nos obligan a escribir código limpio y comprobable. Esto es especialmente cierto para los complementos que tienen una lógica complicada o se comunican con API de terceros.

Escribir pruebas para una base de código de este tipo lo obligará a pensar en cómo se ve la arquitectura de su código para que pueda escribir fácilmente pruebas automatizadas, sin mencionar el tiempo y el dinero que ahorrará al no tener que probar todo manualmente.

Si cree que esto es algo de lo que podría beneficiarse, siéntase libre de usarlo y destaque el repositorio en GitHub.

Con suerte, esto alentará a más desarrolladores de WordPress a usar herramientas que mejorarán sus habilidades de codificación.