Esperamos que hayas consultado nuestra nueva guía para colaboradores y que lo tengas todo listo para enviar tu primer parche — ¡gracias! Pero antes de enviar tu archivo .diff al mundo, ejecuta una prueba unitaria para asegurarte de que todo funciona como debería.
¿Nunca has escrito o ejecutado una prueba unitaria? Aquí tienes una guía rápida para empezar y conocer las prácticas recomendadas.
¿Por qué hacer pruebas unitarias?
Desde Jetpack 2.3.4 en adelante, toda funcionalidad nueva debe ir acompañada de una prueba unitaria satisfactoria. Las pruebas unitarias son pequeños fragmentos de código que garantizan que el código nuevo funciona como se espera.
Las pruebas unitarias son una parte fundamental de tu contribución a Jetpack: verifican que Jetpack funciona como se espera y que las actualizaciones no rompen el código existente. Mientras trabajamos juntos para crear nuevas funciones y eliminar errores, las pruebas unitarias proporcionan un control de calidad continuo que mantiene Jetpack sólido y fiable.
Configura un entorno de pruebas unitarias
Para ejecutar pruebas locales, tendrás que instalar PHPUnit y asegurarte de que has configurado algunos requisitos adicionales — aquí tienes un resumen. (Puedes consultar aquí la versión detallada.)
Instala PHPUnit
PHPUnit se distribuye mediante PEAR. Para asegurarte de que puedes obtener todos los componentes necesarios, añade los siguientes canales de PEAR:
sudo pear channel-discover pear.phpunit.de
sudo pear channel-discover components.ez.no
sudo pear channel-discover pear.symfony-project.com
Cuando hayas descargado los archivos, ejecuta un comando de instalación para configurarlo todo:
sudo pear install phpunit/PHPUnitObtén la base de código de pruebas de WordPress
Las pruebas unitarias de los plugins utilizan la misma base de código que las pruebas unitarias del núcleo de WordPress. Descarga una copia con:
svn checkout http://unit-tests.svn.wordpress.org/trunk wordpress-tests
Obtén Jetpack
Descarga el código de Jetpack y asegúrate de guardarlo en wordpress/wp-content/plugins.
Tienes dos opciones para obtener el código, según el software de control de versiones que prefieras:
Subversion: descarga el código del repositorio de plugins de WordPress.org usando trunk:
svn checkout http://plugins.svn.wordpress.org/jetpack/trunk jetpack
GitHub: clona el fork de GitHub mantenido por @blobaugh. (Este fork también ejecuta pruebas automatizadas con Travis-CI.)
git clone git@github.com:blobaugh/Jetpack.git
ogit clone https://github.com/blobaugh/Jetpack.git
Escribe pruebas
Cuando tengas un entorno de pruebas y la base de código, ¡es hora de escribir una prueba! Las pruebas se encuentran en trunk/tests en WordPress.org o en la carpeta tests de GitHub.
Crea un archivo de prueba nuevo
Al crear archivos de prueba nuevos, todos deben llamarse «test_.php» (donde «test» es igual que el nombre del archivo que contiene el código que se está probando). Las pruebas se encuentran dentro de clases llamadas:
class WP_Test_ extends WP_UnitTestCase
donde «Test» es igual que el nombre de la clase que contiene el código que se va a probar
Escribe una buena prueba
Estas son algunas directrices generales para escribir pruebas unitarias:
- Las pruebas deben ser específicas — prueba una función cada vez.
- Las pruebas deben ser ortogonales (independientes) de todas las demás pruebas. No deben depender de que otras pruebas se ejecuten o se superen.
- Las pruebas deben estar diseñadas para superarse — intentas demostrar que algo funciona, no que falla.
- Las pruebas deben poder repetirse.
- Una función puede (y probablemente debería) tener asociadas varias pruebas: una para cada condición posible.
- Crea una prueba nueva cada vez que encuentres un error para asegurarte de que se detectará si vuelve a aparecer en el futuro.
- Usa datos estáticos en las pruebas para obtener resultados claros. Los datos dinámicos pueden provocar fallos difíciles de diagnosticar
- Al probar servicios externos, es mejor recrear los detalles del servicio (los datos recibidos, el estado de la API, etc.) que conectarse al servicio real.
- Usa nombres descriptivos para las pruebas, de modo que todo el mundo tenga claro qué se está probando; los nombres de método largos no son un problema.
Ejecuta las pruebas
Ahora que has configurado las pruebas unitarias y has escrito algunas pruebas nuevas, específicas y claras, ¡es hora de ejecutarlas! Siempre debes ejecutar las pruebas localmente para asegurarte de que tu código funciona correctamente antes de crear un parche o insertar el código en trunk.
Pruebas locales
Asegúrate de estar en el directorio del plugin de Jetpack y escribe:
phpunit
Pruebas con Travis-CI
Probar con Travis-CI es tan sencillo como volver a hacer commit del código en el fork de GitHub de @blobaugh y visitar https://travis-ci.org/blobaugh/Jetpack. Poco después debería iniciarse una nueva prueba.
Pruebas fallidas
La prueba ha fallado. ¿Y ahora qué?
Y, sobre todo, ¡nada de trampas! Los parches enviados con pruebas fallidas no se aceptarán en trunk. No intentes evitarlo eliminando la prueba — un parche inestable perjudica a todos los sitios que usan Jetpack, así que debemos ser estrictos al respecto.
Por suerte, PHP Unit te indica qué prueba ha fallado, para que puedas usar esos datos y actualizar el código a fin de resolver el problema. Si el fallo se produce en una función que ya existía, es probable que tu función esté interactuando con ella de una forma que provoca el fallo.
Si has probado todo lo que se te ocurre y las pruebas siguen fallando, ponte en contacto con nosotros directamente — estaremos encantados de ayudarte a solucionar el problema.
¿Quieres convertirte en un experto en pruebas unitarias? Consulta estos magníficos recursos:
- El fork de Jetpack de Ben Lobaugh
- Útil para realizar pruebas automatizadas con Travis-CI
- Pruebas automatizadas con Travis-CI – basadas en el fork de Ben Lobaugh
- Visualiza y comparte informes de aprobadas/fallidas del fork de Ben
- Nikolay Bachiyski presenta las pruebas unitarias en WordCamp
- Nikolay presenta el proceso de pruebas unitarias con una demostración en directo
- Diapositivas de WordCamp de Nikolay Bachiyski
- El libro XUnit Patterns
- El libro que debes leer sobre cómo crear buenas pruebas y patrones de pruebas
- Manual de documentación sobre pruebas unitarias de PHP
- El Codex sobre cómo crear pruebas con PHP Unit


