Características
Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:- Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continua.
- Completas: deben cubrir la mayor cantidad de código.
- Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua.
- Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra.
- Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.
Ventajas
El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas. Proporcionan un contrato escrito que el trozo de código debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas básicas:- Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura (lo que se ha dado en llamar refactorización), puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los nuevos cambios no han introducido errores.
- Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración.
- Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo.
- Separación de la interfaz y la implementación: Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el comportamiento de objetos complejos.
- Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos.
En esta imagen se muestra lo que se considera una representación clásica de Software Testing White Box o pruebas de caja blanca, en este tipo de pruebas el cubo representaría un sistema en donde se pueden observar los diversos componentes que forman parte del mismo, cada uno de estos componentes debe ser probado en su totalidad (óvalos), y también sus interfases o comunicaciones con los demás componentes (flechas), este tipo de pruebas también son llamadas pruebas de caja de cristal ya que este útlimo termino representa mejor el tipo de pruebas.
Caja negra
· pruebas de caja opaca
· pruebas funcionales
· pruebas Pde entrada/salida
· pruebas inducidas por los datos
Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datos como entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo por dentro. Las pruebas de caja negra están especialmente indicadas en aquellos módulos que van a ser interfaz con el usuario (en sentido general: teclado, pantalla, ficheros, canales de comunicaciones, etc etc) Este comentario no obsta para que sean útiles en cualquier módulo del sistema.
Fuentes:
http://www.calidadysoftware.com/testing/pruebas_unitarias1.php
No hay comentarios:
Publicar un comentario