En el caso de las pruebas automatizados significa que hay que tener todas esas expresiones almacenadas en forma de pruebas de manera que se lance un instrucción o se pulse un botón de manera que se ejecuten y comprueben todas esas expresiones. Esto sugiere:
- Que las expresiones tienen que ser binarias. Funciona o no funciona.
- El estado de las expresiones las comprueba el entorno llamando a alguna variantes de un método «assert()».
Las afirmaciones tienen que ser lo más precisas posibles. Si un el área de un rectángulo tiene que ser 50, di que este debería ser 50 y (assertTrue($rectangle->area() == 50)) y no algo maś genérico como (assertTrue($rectangle->area() != 0)).
Es recomendable revisar si la librería xUnit tiene una afirmación especial para comparar valores así una entrada para un mensaje de error en el que podamos indicar qué está sucediendo. Por ejemplo,
Las pruebas no deberían en ningún caso depender de la implementación por lo que si esta cambia, las pruebas, deberían seguir ejecutándose normalmente.
Fixture
Cuando tenemos varias pruebas que utilizan un objeto común podemos sobreescribir el método «setUp()» de la prueba e inicializar el objeto común.Un ejemplo realmente simple podría ser inicializar un objeto común a varias pruebas.
En este caso podríamos deshacernos de la duplicación:
La relación entre las subclases de «TestCase» y las instancias de aquellas subclase es una de las partes más complicadas de xUnit. Cada nuevo tipo de «fixture» debería ser una nueva subclase de «TestCase». Cada nuevo «fixture» se crea en una instancia de esa subclase, se usa y se descarta.
En el ejemplo, si queremos escribir una prueba para un rectangulo que no esté vacío entonces habrá que escribir una nueva clase, «NormalRectangleTest». En general, si hay un «fixture» ligeramente diferente entonces hay que crear una nueva clase de «TestCase».
External Fixture
La manera de liberar recursos externos en el «fixture» es sobreescribir el método «tearDown()» y liberar estos recursos.El objetivo de las pruebas es comprobar si el código funciona pero las pruebas tienen que ejecutarse de manera independiente por lo que el estado debe ser siempre el mismo antes y después de ejecutarse una prueba.
Por ejemplo, si se abre un archivo al final de la ejecución de la prueba debería cerrarse.
Si «MyFile» se usa en varios pruebas entonces se podría hacer parte del «fixture».
Primero, si se utiliza en varias pruebas se puede apreciar que hay una duplicación de la cláusula «finally» que indica que se está perdiendo algo en el diseño. Segundo hay que cerrar el archivo mediante el método «close()» lo que se puede olvidar con cierta facilidad. Por último hay varios componentes en la prueba inicial, que son la parte «try», la parte «finally» y el propio cierre.
xUnit garantiza ejecutar el método «tearDown()» después de ejecutar el método de prueba e independientemente de lo que pase en este método. Así que se puede transformar el código anterior en el siguiente.
Test Method
Los método de prueba, por convección, se representan con un método que comienza con la palabra «test».En el caso de utilizar «fixtures» todas las pruebas que comparten una misma «fixture» serán método de la misma clase. Las pruebas que tengan un «fixture» distinto tendrán una clase distinta.
Los métodos de prueba deberían tener un nombre descriptivo que comunique la intención de lo que se está probando.
Los método de prueba deberían ser fáciles de leer y deberían tener pocas líneas. Si un método de prueba se vuelve complejo de entender es posible que se necesite hacer varios métodos de prueba más sencillos.
Exception Test
Hay ocasiones en la que queremos probar si una excepción se lanza durante una ejecución. La prueba fallará sólo si la excepción no se lanza.Alltest
Aunque actualmente la mayoría de IDE son capaces de ejecutar todos las pruebas.Si se añade un prueba a un paquete y se añade un método de pruebas la siguiente vez que se ejecuten todos las pruebas también se debería ejecutar esta nueva prueba. En el caso de que el IDE no xUnit no soporte esta característica cada paquete debería declarar una clase «AllTest» que implemente un método estático «suite()» que devuelva una «TestSuite».
Se puede añadir este «AllTest» al método «main()» así la clase puede ejecutarse desde el IDE o la línea de comandos.
No hay comentarios:
Publicar un comentario