La guía para principiantes de las pruebas unitarias ¿Qué son las pruebas unitarias?

Dependiendo de sus antecedentes, puede o no haber oído hablar de pruebas unitarias, desarrollo dirigido por pruebas, desarrollo basado en el comportamiento o algún otro tipo de metodología de prueba. Muchas veces, estas metodologías se aplican en el contexto de sistemas o aplicaciones de software más grandes y menos en el contexto de proyectos basados ​​en WordPress (aunque es ¡mejorando!)

Francamente, la comunidad de desarrollo está un poco dividida en las pruebas de software automatizadas: hay algunas personas que piensan que deberían realizarse pruebas para el 100% de todo su código, algunas creen que el 80% es suficiente, alrededor del 50% y algunas están contentas con 20% más o menos. Cualquiera que sea el caso, este artículo no se trata de argumentar un caso para el nivel de pruebas que debe tener en su proyecto ni está tomando una posición en las pruebas generales de software.

En su lugar, vamos a echar un vistazo a lo que se requiere para comenzar a trabajar con las pruebas unitarias de sus proyectos de desarrollo de WordPress. Vamos a acercarnos a esta serie desde la perspectiva de un principiante absoluto para que podamos comprender los beneficios de las pruebas unitarias y cómo configurar nuestro entorno para que sea compatible con las bibliotecas de pruebas unitarias para que podamos comenzar a hacer esto en nuestro trabajo futuro. Finalmente, todo esto se hará construyendo y probando un complemento simple y comprobable desde cero..


¿Qué es la prueba unitaria??

Antes de comenzar a configurar nuestro entorno y escribir cualquier código, definamos exactamente qué es la prueba de unidad, por qué vale la pena hacerlo y cómo comenzar a incorporarlo en nuestros proyectos..

En un nivel alto, las pruebas unitarias se refieren a la práctica de probar ciertas funciones y áreas, o unidades, de nuestro código. Esto nos permite verificar que nuestras funciones funcionan como se espera. Es decir, para cualquier función y dado un conjunto de entradas, podemos determinar si la función está devolviendo los valores correctos y manejaremos las fallas con gracia durante el curso de la ejecución si se proporcionara una entrada no válida..

En última instancia, esto nos ayuda a identificar fallas en nuestros algoritmos y / o lógica para ayudar a mejorar la calidad del código que compone una determinada función. A medida que comienza a escribir más y más pruebas, termina creando un conjunto de pruebas que puede ejecutar en cualquier momento durante el desarrollo para verificar continuamente la calidad de su trabajo..

Una segunda ventaja de enfocar el desarrollo desde una perspectiva de prueba unitaria es que probablemente estará escribiendo un código que sea fácil de probar. Dado que las pruebas unitarias requieren que su código sea fácilmente comprobable, significa que su código debe ser compatible con este tipo particular de evaluación. Como tal, es más probable que tenga un número mayor de funciones más pequeñas y más enfocadas que proporcionan una sola operación en un conjunto de datos en lugar de funciones grandes que realizan una serie de operaciones diferentes.

Una tercera ventaja para escribir pruebas unitarias sólidas y un código bien probado es que puede evitar que los cambios futuros rompan la funcionalidad. Ya que está probando su código a medida que introduce su funcionalidad, comenzará a desarrollar un conjunto de casos de prueba que se pueden ejecutar cada vez que trabaje en su lógica. Cuando ocurre una falla, usted sabe que tiene algo que tratar.

Por supuesto, esto conlleva el gasto de tiempo para escribir un conjunto de pruebas al principio del desarrollo, pero a medida que el proyecto crece, simplemente puede ejecutar las pruebas que ha desarrollado para garantizar que la funcionalidad existente no se rompa cuando se presenta una nueva funcionalidad. introducido.


Planificación de nuestro complemento

Una de las mejores maneras de comenzar con las pruebas unitarias es hacerlo en el contexto de una aplicación práctica. A lo largo de esta serie de dos partes, vamos a construir un plugin simple y escribir pruebas para cubrir toda la funcionalidad..

Primero, planifiquemos el proyecto: vamos a escribir un pequeño complemento que agregará un mensaje simple en la parte superior de una sola publicación que da la bienvenida al usuario en función de cómo haya encontrado una publicación de blog específica. La idea es muy similar a Welcome Reader, pero no incluye tanta funcionalidad, simplemente estamos construyendo una demostración para conocer los entresijos de las pruebas..

De todos modos, así es como funcionará el plugin:

  • Si el usuario navega al sitio desde Google, le daremos un mensaje único
  • Si el usuario navega al sitio desde Twitter, le daremos un mensaje único.
  • De lo contrario, no mostraremos nada.

Bastante sencillo, ¿verdad? Esto también proporcionará una base sobre la cual agregar mensajes personalizados para otros servicios y ampliar aún más nuestras capacidades de prueba de unidad si así lo desea..


Preparando el medio ambiente

Para realizar una prueba unitaria de nuestro código, necesitaremos una biblioteca de terceros que incluiremos en nuestro proyecto que ejecutará las pruebas que escribimos. En esta serie, vamos a utilizar PHPUnit. Puedes agarrar una copia aquí.

Luego, debemos preparar nuestro entorno de desarrollo, apagar nuestro complemento e incluir las bibliotecas necesarias para probar nuestro código. Este artículo supone que ya tiene una instalación funcional de WordPress en funcionamiento.

Entonces, primero, vamos a preparar el directorio de complementos:

  • En / wp-content / plugins crear un directorio llamado Hola lector
  • En el Hola lector directorio, crea un archivo llamado plugin.php y un directorio llamado pruebas
  • Apagaremos el complemento para asegurarnos de que WordPress está viendo correctamente nuestro proyecto
  • Importaremos las bibliotecas de pruebas unitarias para que podamos comenzar a escribir nuestras pruebas.

Aquí está el esqueleto del complemento que vamos a crear:

/ * Nombre del complemento: URI del complemento de Hello Reader: http://github.com/tommcfarlin/Hello-Reader Descripción: Un complemento simple que se utiliza para ayudar a demostrar las pruebas de unidad en el contexto de WordPress. Versión: 1.0 Autor: Tom McFarlin Autor URI: http://tom.mcfarl.in Autor Correo electrónico: [email protected] Licencia: Copyright 2012 Tom McFarlin ([email protected]) Este programa es software libre; puede redistribuirlo y / o modificarlo según los términos de la Licencia Pública General de GNU, versión 2, tal como lo publica Free Software Foundation. Este programa se distribuye con la esperanza de que sea útil, pero SIN NINGUNA GARANTÍA; sin ni siquiera la garantía implícita de COMERCIABILIDAD o APTITUD PARA UN PROPÓSITO PARTICULAR. Vea la Licencia Pública General de GNU para más detalles. Debería haber recibido una copia de la Licencia Pública General de GNU junto con este programa; si no, escriba a la Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 EE. UU. * / // Solo cree una instancia del complemento si aún no existe en GLOBALS si (! array_key_exists ('hello-reader', $ GLOBALS)) class Hello_Reader function __construct ()  // end constructor // end class // Almacena una referencia al complemento en GLOBALS para que nuestras pruebas unitarias puedan acceder a él $ GLOBALES ['hello-reader'] = new Hello_Reader ();  // terminara si

En este punto, debería poder navegar a los "Complementos" en su Tablero de WordPress y ver una entrada para "Hola lector". Obviamente, este complemento no hace nada por el momento, nos enfocaremos en eso (y también por qué estamos aprovechando el $ GLOBALES array) en el siguiente artículo.

Finalmente, configuremos el marco de prueba para que podamos escribir nuestras pruebas. Primero, necesitaremos instalar PHPUnit y luego necesitaremos instalar las pruebas de WordPress..

Nota: La siguiente sección requerirá realizar algún trabajo con el terminal y probablemente requerirá que emita algunos comandos para crear enlaces simbólicos. He intentado hacer esto lo más sencillo y fácil posible, pero cada sistema operativo y configuración serán diferentes. Por favor, siga cuidadosamente y lo invito a compartir sus instrucciones para sus sistemas operativos en los comentarios..

Instalando PHPUnit

PHPUnit es un paquete de marco de prueba de unidad específicamente para PHP. Las pruebas de WordPress y el marco que vamos a utilizar para escribir nuestras pruebas de WordPress dependen de esto. Desafortunadamente, la instalación varía según la plataforma. Actualmente estoy ejecutando Mac OS X Lion con MAMP Pro y PHP 5.3.6. Si está ejecutando una plataforma diferente, asegúrese de consultar la documentación o no dude en compartir sus pasos en los comentarios..

Primero abra un terminal y actualice pear (esta es la facilidad que usaremos para instalar PHPUnit):

$ cd /Applications/MAMP/bin/php/php5.3.6/bin
$ sudo ./pear mejora pera

A continuación, indique a Pear que use los repositorios que especificaremos en el terminal:

$ sudo /Applications/MAMP/bin/php/php5.3.6/bin/pear config-set auto_discover 1

Después de eso, instale Pear emitiendo el siguiente comando:

$ sudo /Applications/MAMP/bin/php/php5.3.6/bin/pear install pear.phpunit.de/PHPUnit

Esto instalará PHPUnit dentro del contexto de su instalación MAMP. Para probarlo, ejecute el siguiente comando en su sesión de terminal:

$ /Aplicaciones/MAMP/bin/php/php5.3.6/bin/phpunit --version

Después de lo cual se debe mostrar el siguiente mensaje:

PHPUnit 3.6.11 por Sebastian Bergmann.

Nota: Si obtiene un error de terminal que menciona "unserialize ()", existe una discrepancia entre la configuración de pera y su versión de pera. Para resolverlo, ejecute el siguiente comando (esto simplemente cambia el nombre del archivo si desea restaurarlo más tarde):

$ /Applications/MAMP/bin/php/php5.3.6/conf/pear.conf /Applications/MAMP/bin/php/php5.3.6/conf/pear.conf.old

Instalar las pruebas de WordPress

Ahora que tenemos PHPUnit instalado y funcionando, es hora de configurar el Marco de prueba de WordPress. Puedes tomar el paquete de GitHub. Si está cómodo clonando el repositorio, siéntase libre de hacerlo; de lo contrario, simplemente descargue un archivo del proyecto y extráigalo en el prueba directorio que creamos anteriormente en este artículo.

Antes de ejecutar las pruebas, deberemos crear un archivo de configuración para ejecutar las pruebas de WordPress. Esto es exactamente como editar el wp-config.php archivo con una nueva instalación de WordPress, pero lo estamos haciendo para una base de datos de prueba en su lugar. A continuación, he pegado mi archivo de configuración y he agregado comentarios. También me aseguraré de enviar esto al repositorio de GitHub de este artículo..

/ * Ruta al código base de WordPress en relación con la ubicación de estas pruebas. Ya que están incluidos en nuestro complemento, nos referimos a algunos directorios arriba. * / define ('ABSPATH', '… /… /… /… /… /'); / * El nombre de la base de datos para ejecutar las pruebas. Asegúrese de que esta es una base de datos solo para realizar pruebas, ya que se crea y destruye durante las pruebas. * / define ('DB_NAME', 'throwaway'); / * Las credenciales habituales para una base de datos local. * / define ('DB_USER', 'root'); define ('DB_PASSWORD', "); define ('DB_HOST', 'localhost'); define ('DB_CHARSET', 'utf8'); define ('DB_COLLATE',"); define ('WPLANG', "); define ('WP_DEBUG', true); define ('WP_DEBUG_DISPLAY', true); define ('WP_TESTS_DOMAIN', 'localhost'); define ('WP_TESTS_EMAIL','[email protected] '); define (' WP_TESTS_TITLE ',' Test Blog '); / * No se preocupa por probar redes o subdominios, por lo que se establece en falso. * / define (' WP_TESTS_NETWORK_TITLE ',' Test Network '); false); $ base = '/'; / * Cron intenta realizar una solicitud HTTP al blog, que siempre falla, porque las pruebas se ejecutan solo en modo CLI * / define ('DISABLE_WP_CRON', verdadero); / * También no interesado en probar multisitio para este proyecto, por lo que se establece en falso. * / define ('WP_ALLOW_MULTISITE', falso); if (WP_ALLOW_MULTISITE) define ('WP_TESTS_BLOGS', 'primero, segundo, tercero, cuarto'); &&! defined ('WP_INSTALLING')) define ('SUBDOMAIN_INSTALL', WP_TESTS_SUBDOMAIN_INSTALL); define ('MULTISITE', true); barrido de las '' '' '' '' '' '' '' '' '' '' '' '' efine ('SITE_ID_CURRENT_SITE', 1); define ('BLOG_ID_CURRENT_SITE', 1);  $ table_prefix = 'wp_';

Para verificar que ha instalado las pruebas correctamente, puede ejecutar el siguiente comando en su Terminal:

$ /Aplicaciones/MAMP/bin/php/php5.3.6/bin/phpunit todo

Si obtiene un error, es porque las pruebas de WordPress están intentando usar un socket para la base de datos MySQL en lugar de la que usa MAMP. Para solucionar esto, necesitamos crear un enlace simbólico desde el zócalo de MAMP a la ubicación en el disco que están usando las pruebas de la unidad. Emita los siguientes comandos en su sesión de terminal:

$ sudo mkdir / var / mysql $ sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock /var/mysql/mysql.sock $ sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock / var / mysql / mysql.sock

Ahora, intente ejecutar las pruebas nuevamente y debería ver algo como la siguiente captura de pantalla.

Nuevamente, su millaje puede variar según la plataforma que use, así que no dude en compartir su experiencia en los comentarios o incluso comprometerse con el archivo README en GitHub para que otros puedan tener un punto de referencia..

En este punto, estamos listos para comenzar a construir nuestro complemento y escribir nuestras pruebas de unidad. El código anterior se agregó a GitHub y lo desarrollaré a medida que trabajemos en el siguiente artículo de la serie. Mientras tanto, asegúrese de configurar el entorno y de que está listo para comenzar el desarrollo. En el siguiente artículo, comenzaremos a escribir pruebas, crear nuestro complemento y ver cómo el proyecto completo se reúne de principio a fin..


Recursos

  • PHPUnit
  • Pruebas de WordPress
  • Hola lector