| Traducción del artículo original ubicado en: http://docs.joomla.org/Unit_Testing |
La práctica también anima a escribir mas corto, mejor acoplado, mas reutilizable, y unidades de código mas fáciles de mantener, estos beneficios son a menudo mayores que los beneficios de hacer las pruebas unitarias de forma individual con una herramienta de control de calidad. Cuando se realizan de esta manera la corrección se convierte en un subproducto del proceso mas que del resultado. Para una buena explicación general sobre pruebas unitarias, visite el articulo de la Wikipedia.
Pruebas unitarias en Código Abierto
Los proyectos de código abierto, con múltiples desarrolladores trabajando en paralelo por todo el mundo, pueden beneficiarse mucho de las pruebas unitarias. Los principales beneficios son:
- Las pruebas unitarias ayudan a resaltar los casos donde lo que parecen pequeños cambios producen fallos inesperados.
- Las pruebas unitarias ayudan a especificar como una clase se debería comportar.
- Las pruebas unitarias pueden exponer defectos del diseño muy al principio del desarrollo.
- Las pruebas unitarias hacen de grandes ejemplos. Son sitio perfecto para los desarrolladores para aprender como usar el código.
La jerarquía de las pruebas: Unidad, subsistema, integradas.
Los sistemas de software de pruebas corren sobre un espectro desde pruebas unitarias «puras» hasta sistemas de pruebas completamente integrados. Hemos descrito las pruebas unitarias de bajo nivel arriba. Las pruebas integradas típicamente implican algún tipo de script que simule las acciones del usuario y que verifique que el resultado es el esperado. Este tipo de pruebas «de extremo a extremo» verifican que todas las partes del sistema funcionan correctamente.
Es una pena que no haya nomenclatura clara para describir todas las etapas intermedias de las pruebas. El siguiente paso mas allá de probar una única unidad de código es probar el subsistema. Una prueba de subsistema verifica que dos o mas unidades de código interaccionan correctamente para producir el resultado deseado. En el caso mas simple, una prueba de subsistema puede ser creada por simplemente reemplazar objetos simulados por objetos reales y correr las pruebas unitarias en el nivel mas alto del modulo. En la practica, esto tiende a no funcionar tan bien como esperaríamos, porque los datos de la prueba unitaria no fueron diseñados para una prueba de subsistema, o porque la naturaleza de los casos de pruebas tienen que ser cambiados para poder probar totalmente el subsistema. Después de todo esto hay un pequeño punto en simplemente repetir los casos de prueba unitaria; el objetivo de una prueba de subsistema debería ser probar las condiciones de contorno y casos especiales que serian difíciles de duplicar en las pruebas unitarias.
Una vez que el subsistema a sido probado, puede ser integrado en un sistema mayor, que todavía sea un subconjunto del producto completo. Las pruebas pueden ser escritas para mayores y mayores subsistemas, pero en cada etapa la complexidad de las pruebas se incrementa. En algún punto, el esfuerzo necesario para crear las pruebas excede los beneficios de hacerlas. Aquí es donde las pruebas integradas vienen.
Objetos de prueba
El propósito de las pruebas unitarias es aislar un módulo de código. Una prueba que pruebe solo una cosa da mejor información que una prueba que contenga unas cuantas interacciones de objetos. Pero, ¿como aislamos un objeto de sus dependencias? Escribiendo clases stub. xUnit Patterns define una jerarquía de clases ficticias, que van de simple a complejo:
- Dummy - Define atributos y métodos de una clase ficticia
- Fake - Proporciona respuestas enlatadas a las llamadas de método y valores fijos de los atributos. Buena para la velocidad.
- Stub - Permite que la prueba defina respuestas a llamadas de método (valores de retorno, excepciones) para simular el objeto dependiente.
- Spy - Un Fake o Stub que registra las llamadas a métodos y los parámetros para análisis posteriores.
- Mock - Un Fake o Stub con un conjunto de expectativas -- llamadas de metódo y parametros -- que son verificadas automáticamente.
Pruebas unitarias en Joomla!
Las capacidades de pruebas unitarias en Joomla estan siendo desarrolladas constantemente.
El Joomla Platform GitHub repositorio contiene pruebas PHPUnit dentro del subdirectorio de pruebas /tests. Ver Haciendo pruebas automáticas para versión 1.6 para instrucciones de creación de pruebas en su IDE.
El equipo de pruebas unitarias
Si puedes confiar en el código base de Joomla, entonces deberías considerar en formar parte del equipo de pruebas unitarias!
Escribiendo pruebas simultáneamente con código (o incluso antes) no solo es una buena manera de ahorrar tiempo de desarrollo, además es una excelente herramienta para defenderse contra las regresiones. Escribiendo pruebas al principio del ciclo de desarrollo ayuda también a identificar y resolver problemas de diseño antes, lo que reduce refactorización.
Si quieres empezar a hacer pruebas unitarias, ponte en contacto con Alan Langford (instance) o Ray Tsai (mihu).
Trabajo actual
- Ya no hace falta parchear el código principal activar las pruebas unitarias.
- Técnicas básicas para objetos mock están definidas.
- Estrategias para afrontar la configuración local no esta completa pero hay un plan.
- Archivos del tipo class-sequence-type-Test.php, por ejemplo JObject-0000-class-Test.php uso PHPUnit.
- Los JDate tests representan un buen ejemplo de data-driven tests, pero no corren en la versión 1.5 del código base.
- Previas pruebas funcionales, como JFTP, no han sido movidas todavía al entorno PHPUnit.
- El Test runner personalizado ya no es necesario. Los test actuales corren con las última versión de PHPUnit 3.4. Este código sera próximamente PHPUnut 3.4.1 Gracias a Sebastian Bergmann por su excelente proyecto.
Escribiendo pruebas unitarias
A riesgo de afirmar lo obvio, en el «mas puro» caso el propósito de una prueba unitaria es aislar una unidad de código de su entorno y probar la operación de ese código.
Este aislamiento se consigue normalmente escribiendo dummy clases que simulen el código en su entorno. Estos objetos dummy pueden ser pasivos, simulando simplemente el entorno, o puden ser mas activos, haciendo seguimiento de como están siendo utilizados por la unidad de prueba e informar de cualquier variación de la conducta esperada. Vea Mock Objects in Joomla para un ejemplo mas detallado.
Un interesante aspecto de escribir tests es que se convierten en detalladas especificaciones técnicas de facto de las interfaces entre unidades de código. El hecho de que estas especificaciones pueden ser verificadas de forma automática hace de ellos un recurso excelente cuando se refactoriza el código.
El código de pruebas tiene algunas plantillas diseñadas para iniciar la prueba de forma rápida. Son:
/unittest/sample-datatest-php.txt /unittest/sample-simpletest.php.txt
Aqui hay algunos ejemplos de pruebas: Simple Example, Data Driven Example, Plugin Example, UI Example.
Corriendo Pruebas Unitarias
Los archivos siguen al formulario classnameTest.php, por ejemplo JObjectTest.php. Para pruebas que no están basadas en clases, use el nombre del archivo a probar.
Las pruebas unitarias Joomla usan estándar PHPUnit test runner. Vea http://www.phpunit.de para documentación.
Como ponerlo en marcha
Antes de empezar asegúrese de tener instalado PHPUnit y por supuesto PHP (5!) correctamente...
Para tener las pruebas unitarias funcionando en su instalación de Joomla!, siga los siguientes pasos:
- Cree una prueba de insalación de Joomla! Como va a usar SVN para comprovar el proyecto de prueba, no es deseable comprebar el Joomla! con el SVN. en vez de eso, simplemente descomprima un archivo normal de Joomla! Si esta usando Eclipse, puede crear una carpeta en su lugar de trabajo de Eclipse para la instalación de Joomla!, pero no cree un proyecto de Eclipse aún.
- En la raiz de checkout (o exportación) la última versión del código de pruebas unitarias de SVN "/testing/trunk/1.5/unittest" o "/testing/trunk/1.6/unittest" para su instalación base. Esto creara una sub-carpeta "/unittest" en su instalación Joomla!. Si usa Eclipse, importe el proyecto desde el SVN y use la misma carpeta usada anteriormente.
- Desde la linea de comando, cambie al directorio unittest.
- Ejecute la prueba unitaria desde la linea de comando usando este comando: phpunit tests
Las prueba unitaria se ejecutará, y los resultados se presentaran. Se verán una serie de puntos para cada prueba pasada y otras letras para las pruebas falladas.
Vea http://www.phpunit.de/manual/current/en/textui.html para ayuda usando el --filter switch en ciertas pruebas. Hay además muchas lineas de comando que se pueden utilizar para recibir los resultados en diferentes formatos.
Solución de problemas
Las configuraciones proporcionadas deberian funcionar correctamente. Hemos visto algunos problemas (la causa es desconocida todavía). Si aparece algún error como el siguiente, la solución es bastante fácil.
file=/var/www/unittest/runtests.php posn=17 base=runtests.php /var/www JPATH_BASE does not point to a valid Joomla! installation: JPATH_BASE = /var/www Please modify your copy of "TestConfiguration.php"
Modifica el archivo "TestConfiguration.php" y cambia la definición del JPATH_BASE para que señale a tu insatalación de Joomla!, en el siguiente ejemplo la instalación se instala en "/var/www/update".
define('JPATH_BASE', '/var/www/update');
FAQ
¿Porque no puedo utilizar "phpunit testname.php" para hacer mi prueba?
La instalación de prueba tiene que hacer bastante trabajo para carga el framework de Joomla! y ser capaz de inyectar clases simuladas. Es dificil hacer esto desde PHPUnit test runner, asi que hemos hecho el nuestro propio. Además, el Joomla test runner tine opciones específicas diseñadas para seleccionar pruebas concretas de forma fácil. Con el tiempo añadiremos mas funcionalidades al test runner para que tenga la mayoria de las capacidades de phpunit command.
