Hasta ahora, solo tenemos dos pruebas para Array y la función incorporada sizeof(). Cuando comenzamos a probar una gran cantidad de funciones array_*(), necesitamos una prueba para cada una. Podemos escribir cada uno desde cero. Sin embargo, un mejor enfoque es escribir la infraestructura de prueba una vez y luego escribir solo las diferentes partes de cada prueba. PHPUnit es una infraestructura de este tipo.
El ejemplo 5 muestra cómo reescribir las dos pruebas del ejemplo 4 usando PHPUnit.
Ejemplo 5. Pruebe Array y sizeof() con PHPUnit
<?php
.
require_once 'PHPUnit2/Framework/TestCase.php';
clase ArrayTest extiende PHPUnit2_Framework_TestCase {
función pública pruebaNewArrayIsEmpty() {
//Crear dispositivo de matriz.
$accesorio = Matriz( );
// Afirma que el tamaño del dispositivo de matriz es 0.
$this->assertEquals(0, sizeof($fixture));
}
función pública testArrayContainsAnElement() {
//Crear dispositivo de matriz.
$fixture = Array( );
// Agrega un miembro al dispositivo de la matriz.
$accesorio[] = 'Elemento';
//Afirma que el tamaño del dispositivo de matriz es 1.
$this->assertEquals(1, sizeof($fixture));
}
}
?>
El ejemplo 5 nos dice que los pasos básicos para usar PHPUnit para escribir pruebas son:
1. La clase de prueba para la clase Class es ClassTest.
2. ClassTest generalmente hereda PHPUnit2_ Framework_TestCase.
3． La prueba es un método público sin parámetros y su nombre es prueba*.
4. En el método de prueba, se utilizan funciones de aserción como afirmarEquals() (ver Tabla 6) para afirmar si el valor real coincide con el valor esperado.
Un marco como PHPUnit necesita resolver una serie de problemas, algunos de los cuales parecen entrar en conflicto entre sí. Las pruebas también deben cumplir las siguientes condiciones:
Fácil de aprender
Las pruebas deben ser fáciles de aprender, de lo contrario, los desarrolladores no aprenderán
Fácil de desarrollar
Las pruebas deben ser fáciles de desarrollar, de lo contrario, los desarrolladores no desarrollarán
Fácil de leer
El código de prueba no debe tener relaciones externas , para que la prueba en sí no se pierda en el desorden.
Fácil de ejecutar
Las pruebas deben ser fáciles de ejecutar y los resultados de la ejecución deben expresarse en un formato claro e inequívoco.
Las pruebasde ejecución rápida
deben ejecutarse rápidamente para que puedan ejecutarse miles de veces al día.
Las pruebasde aislamiento de código
no pueden afectarse entre sí y los cambios en el orden de las pruebas no deberían afectar los resultados.
Composable
Deberíamos poder ejecutar pruebas en cualquier combinación, lo cual es un corolario del aislamiento de código.
Existen dos conflictos principales entre estas limitaciones:
Facilidad de aprendizaje versus Facilidad de desarrollo
. Las pruebas generalmente no requieren toda la flexibilidad de la programación. Muchas herramientas de prueba proporcionan sus propios lenguajes de programación de pruebas. Estos lenguajes solo tienen el conjunto mínimo de funciones necesarias para escribir pruebas. Debido a que no hay ruido que interfiera con el contenido de la prueba, las pruebas escritas son fáciles de leer y escribir. Pero aprender un nuevo sobre de tejido y un nuevo conjunto de herramientas sigue siendo inconveniente y fácilmente confuso.
Aislamiento de código versus ejecución rápida
Si desea que los resultados de una prueba no afecten a otra, debe crear un tema completo para la prueba al comienzo de cada prueba y luego restaurar el estado antes de ejecutarla. Sin embargo, configurar el estado lleva mucho tiempo (por ejemplo, conectarse a la base de datos e inicializar a un estado conocido con datos reales).
La solución de PHPUnit a este problema es utilizar PHP como lenguaje de prueba. A veces, PHP con todas las funciones es demasiado potente para escribir pruebas breves y sencillas, pero los programadores que utilizamos ya tienen experiencia completa con PHP. Debido a que necesitamos convencer a los evaluadores reacios, es extremadamente importante reducir la barrera para escribir estas pruebas iniciales.