La guía para principiantes de las pruebas unitarias: ¿qué es la prueba unitaria?

Spanish (Español) translation by Juan Pablo Diaz Cuartas (you can also view the original English article)

Dependiendo de sus antecedentes, puede o no haber oído hablar de pruebas unitarias, desarrollo basado en pruebas, desarrollo impulsado por 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 está mejorando!)

Francamente, la comunidad de desarrollo está un poco dividida en cuanto a las pruebas automáticas de software: hay personas que piensan que deberían tener pruebas para el 100% de todo el código, algunos creen que el 80% es suficiente, aproximadamente el 50% y algunos están contentos 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 ver lo que se requiere para comenzar a usar unidades de prueba de sus proyectos de desarrollo de WordPress. Nos acercaremos 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 admitir bibliotecas de pruebas unitarias para que podamos comenzar a hacer esto en nuestro trabajo futuro. Finalmente, todo esto se realizará mediante la construcción y prueba de un plugin 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é pruebas unitarias son, por qué vale la pena hacerlo y cómo comenzar a incorporarlas 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 da la capacidad de verificar que nuestras funciones funcionan como se espera. Es decir que para cualquier función y dado un conjunto de entradas, podemos determinar si la función está devolviendo los valores correctos y manejar correctamente las fallas durante el curso de la ejecución si se proporciona 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 para abordar el desarrollo desde la perspectiva de las pruebas unitarias es que probablemente escriba código que sea fácil de probar. Como 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 mayor número de funciones más pequeñas y enfocadas que proporcionan una única operación en un conjunto de datos en lugar de grandes funciones que realizan varias operaciones diferentes.

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

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

Planear nuestro complemento

Una de las mejores formas de comenzar con la prueba unitaria 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 pruebas de escritura 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 le da la bienvenida al usuario en función de cómo han encontrado una publicación de blog específica. La idea es muy similar a la de Welcome Reader, pero no incluirá casi tanta funcionalidad: simplemente estamos creando una demostración para conocer los pormenores de las pruebas.

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

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

Muy 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 pruebas unitarias si así lo desea.

Preparar el ambiente

Con el fin de probar nuestro código en unidades, vamos a necesitar una biblioteca de terceros que incluyamos en nuestro proyecto que realmente ejecutará las pruebas que escribimos. En esta serie, vamos a usar PHPUnit. Puedes tomar una copia aquí.

A continuación, tenemos que preparar nuestro entorno de desarrollo, cerrar nuestro complemento e incluir las bibliotecas necesarias para probar nuestro código. Este artículo asume que ya tienes una instalación funcional de WordPress en funcionamiento.

Entonces, primero, preparemos el directorio del complemento:

En / wp-content / plugins crea un directorio llamado Hello-Reader
En el directorio Hello-Reader, crea un archivo llamado plugin.php y un directorio llamado tests
Vamos a cerrar el plugin para asegurarnos de que WordPress vea nuestro proyecto correctamente
Importaremos las bibliotecas de pruebas unitarias para que podamos comenzar a escribir nuestras pruebas

Aquí está el esqueleto para el plugin que vamos a crear:

/*
Plugin Name: Hello Reader
Plugin URI: http://github.com/tommcfarlin/Hello-Reader
Description: A simple plugin used to help demonstrate unit testing in the context of WordPress.
Version: 1.0
Author: Tom McFarlin
Author URI: http://tom.mcfarl.in
Author Email: tom@tommcfarlin.com
License:

  Copyright 2012 Tom McFarlin (tom@tommcfarlin.com)

  This program is free software; you can redistribute it and/or modify
  it under the terms of the GNU General Public License, version 2, as 
  published by the Free Software Foundation.

  This program is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  GNU General Public License for more details.

  You should have received a copy of the GNU General Public License
  along with this program; if not, write to the Free Software
  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
  
*/
// Only create an instance of the plugin if it doesn't already exists in GLOBALS
if( ! array_key_exists( 'hello-reader', $GLOBALS ) ) { 

  class Hello_Reader {
		 
		function __construct() {
			
		} // end constructor
	  
	} // end class
	
	// Store a reference to the plugin in GLOBALS so that our unit tests can access it
	$GLOBALS['hello-reader'] = new Hello_Reader();
	
} // end if

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 centraremos en eso (y también en por qué estamos aprovechando la matriz $GLOBALS) en el próximo artículo.

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

Nota: La siguiente sección requerirá hacer algún trabajo con el terminal y es probable que requiera que emita algunos comandos para crear enlaces simbólicos. Intenté hacer esto lo más sencillo y fácil posible, pero cada sistema operativo y configuración será diferente. 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 unitario 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 su 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 y / o no dude en compartir sus pasos en los comentarios.

Primero abra una terminal y actualice pear (esta es la instalación que usaremos para instalar PHPUnit):

$ cd / Aplicaciones / MAMP / bin / php / php5.3.6/bin
$ sudo ./pear upgrade pear

Luego, pida a Pear que use repositorios que especificaremos en la 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 de 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 by Sebastian Bergmann.

Nota: Si recibe un error de terminal que menciona "unserialize ()", entonces hay una discrepancia entre la configuración de pera y su versión de pera. Para resolver, emita 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

Instalando las pruebas de WordPress

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

Antes de ejecutar las pruebas, necesitaremos crear un archivo de configuración para ejecutar las pruebas de WordPress. Esto es exactamente como editar el archivo wp-config.php 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.

/* Path to the WordPress codebase in relation to the location of these tests. Since they are included with our plugin, we refer to a few directories above. */
define( 'ABSPATH', '../../../../../' );

/* The name of the database for running the tests. Make sure this is a database just for testing as it's created and trashed during tests. */
define( 'DB_NAME', 'throwaway' );

/* The usual credentials for a local database. */
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', 'tom@tommcfarlin.com' );
define( 'WP_TESTS_TITLE', 'Test Blog' );

/* Not worried about testing networks or subdomains, so setting to false. */
define( 'WP_TESTS_NETWORK_TITLE', 'Test Network' );
define( 'WP_TESTS_SUBDOMAIN_INSTALL', false );
$base = '/';

/* Cron tries to make an HTTP request to the blog, which always fails, because tests are run in CLI mode only */
define( 'DISABLE_WP_CRON', true );

/* Also not interested in testing multisite for this project, so setting to false. */
define( 'WP_ALLOW_MULTISITE', false );
if ( WP_ALLOW_MULTISITE ) {
	define( 'WP_TESTS_BLOGS', 'first,second,third,fourth' );
}
if ( WP_ALLOW_MULTISITE && !defined('WP_INSTALLING') ) {
	define( 'SUBDOMAIN_INSTALL', WP_TESTS_SUBDOMAIN_INSTALL );
	define( 'MULTISITE', true );
	define( 'DOMAIN_CURRENT_SITE', WP_TESTS_DOMAIN );
	define( 'PATH_CURRENT_SITE', '/' );
	define( '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:

$ /Applications/MAMP/bin/php/php5.3.6/bin/phpunit all

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

1	$ sudo mkdir /var/mysql
2	$ sudo ln -s /Applications/MAMP/tmp/mysql/mysql.sock /var/mysql/mysql.sock
3	$ 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.

De nuevo, su millaje puede variar según la plataforma que usa, así que no dude en compartir su experiencia en los comentarios o incluso comprométase 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 unitarias. El código anterior se ha agregado a GitHub y lo construiré mientras trabajamos en el siguiente artículo de la serie. Mientras tanto, asegúrese de obtener la configuración de su entorno y de estar listo para comenzar el desarrollo. En el próximo artículo, empezaremos a escribir pruebas, a crear nuestro complemento y a ver todo el proyecto de principio a fin.