Este articulo no es para tratar sobre ¿porque debemos hacer tests?, ni de como hacerlos es sobre los test de validación y algunos de sus tipos.
Los test de validación son tests que miden algún aspecto de la implementación de nuestro programa contra una expectativa, resultado o comportamiento y nos ayuda a
responder si el programa cumple o no con esa expectativa.
Uno de los beneficios de hacer tests es que al crearlos nos vemos forzados a entender detalladamente el objetivo de nuestro programa. Esto se extiende mas alla de los programadores, tambien el cliente participara ya que para hacer los tests necesitaremos que el cliente sea muy especifico y nos de detalles de como quiere
que se comporte el programa, eso realmente hace nuestro trabajo mas facil.
Los test que validan que el software funciona en condiciones ideales son llamados positive test, test positivos o mejor conocidos como test que prueban el camino feliz (happy path), estos test usan datos de entrada conocidos y que no producen excepciones o condiciones de error. Por lo tanto no nos servirán si queremos validar la infinidad de condiciones en las que el programa puede ser usado. Para esto debemos hacer tests que ejerciten el lado negativo, camino triste o sad path, estos probaran las posibles variaciones que puedan presentarse y que puedan generar un comportamiento no previsto.
Tests de Aceptación:
En los tests de aceptación el desarrollador debe ponerse en los zapatos del cliente y pensar como éste con respecto a las necesidades de sus usuarios. Es común que para estos tests contemos con la presencia del cliente para que detalle lo que desea que el programa haga. El objetivo es proveer confianza de que el sistema cumple con las expectativas del cliente y los usuarios.
Generalmente los test de aceptación son del tipo black box o caja negra, en otras palabras, están enfocados en la usabilidad y funcionalidad de la aplicación mas
que en el detalle tecnico. Por eso intenta replicar el uso real de la aplicación en producción por los usuarios.
Estos test generalmente prueban una gran parte del programa o el programa completo, y pueden consistir de un script que emule las acciones que un humano puede realizar al utilizar el sistema. Una forma de hacerlos es escribir los requerimientos del cliente detalladamente y luego llevarlos a un test, pueden ser escritos por el mismo cliente en un lenguaje coloquial detallando cada acción que requiera que realize el sistema.
Tests Unitarios:
El objetivo de estos tests es buscar defectos en algún componente del programa, (modulos, objetos, clases, etc) estos pueden ser probados separadamente
y verifican su funcionamiento correcto independientemente de otros componentes.
Son escrito por los desarrolladores y del tipo white boox o caja blanca, ya que prueban la funcionalidad interna del código, se dice de caja blanca o transparente porque prueba el código como tal (funciones, metodos, valores de variables), y no una funcionalidad general. Los test unitarios expresan un solo hecho por ello un test unitario no debe depender de otro test u otra funcionalidad.
Estos test permiten la colaboración colectiva, cuando se crean test unitarios permite proteger el componente de ser accidentalmente dañado por otro desarrollador. Tambien permiten la re-factorizacion, después de cada cambio los test unitarios pueden verificar que un cambio en el código no causo un fallo en la funcionalidad y resultados del programa.
Los test unitarios no pueden asegurar que el programa como tal funciona 100% correctamente pero puede demostrar que los componentes que usa el programa funcionan independientemente de otros.
Tests de Integración:
Como su nombre lo indica estos tests prueban la integración de varios componentes, por ejemplo pueden probar que dos test unitarios (o dos componentes
independientes) trabajen en conjunto para producir un resultado esperado, es decir se prueba la interfaz entre esas dos unidades. Los componentes pueden
ser otros modulos, funciones/metodos, clases, servicios externos, bases de datos, etc.
Escribir tests unitarios puede ser una tarea difícil cuando el programa es hecho por varios equipos de trabajo que construyen diferentes modulos y componentes por ello es importante que antes de hacer un test de integración los componentes independientes ya tengan sus test unitarios y cumplan con estos. La idea es probar combinaciones de piezas que eventualmente daran como resultado una funcionalidad completa.
Estos son algunos de los tests que podemos aplicar en nuestros desarrollos, en este blog hemos escrito varios artículos de testing que puedes leer para reforzar tu conocimiento:
