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 aunque 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 me 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 ) y pruebas de integración de WordPress que utilizan el marco de pruebas de Pest.
Ok, entonces, ¿por qué necesitamos estas herramientas?
La principal motivación detrás de la creación de estas 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 una 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 configurar su proyecto debe usar Composer . Es una forma estándar de facto de agregar paquetes a su código.
En tu terminal escribe:
composer require dingo-d/wp-pest-integration-test-setup --devUna vez que haya descargado el paquete y sus dependencias, puede configurar las pruebas de theme escribiendo:
vendor/bin/wp-pest setup themeO, en el caso de que desee configurar pruebas para su plugin, puede escribir:
vendor/bin/wp-pest setup plugin --plugin-slug=your-plugin-slugOpcionalmente, puede proporcionar un --wp-versionparámetro 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=unito
vendor/bin/pest --group=integrationejecutará 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.phpse 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');
});Ejecutar vendor/bin/pest --group=integrationnos 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.14sConclusió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 dele una estrella al repositorio en GitHub.
Con suerte, esto alentará a más desarrolladores de WordPress a usar herramientas que mejorarán sus habilidades de codificación.