Tipos de test en desarrollo ágil con TDD

Por David Muñoz
Developer en OpenSistemas

El desarrollo Dirigido a Test (Test Drive Development) es una técnica de diseño e implementación de software que se centra en tres pilares fundamentales:

1. La implementación de las funciones justas que el cliente necesita y no más.
2. La minimización del número de defectos que llegan al software en fase de producción.
3. La producción de software modular, altamente reutilizable y preparado para el cambio.

Es decir, TDD no es solo un técnica para que nuestro código tenga una buena cobertura de test, sino que es más una metodología o filosofía para generar aplicaciones de calidad. Con esto se debe entender que no consiste en escribir miles de test sin un enfoque concreto, sino que consiste en definir primero, antes de ponernos a programar, los tipos de test que se vamos a necesitar, para que van a servir y que ejemplo del lenguaje humano van a validar. (Ejemplo: Si compro una camiseta en viernes se tiene que aplicar un 50% de descuento al precio final), de tal manera, que consigamos un software de calidad, sin funcionalidades extras y con un grado de fiabilidad y escalabilidad muy elevado.

Tipos de test en desarrollo del software

En función de la perspectiva con la que miremos el test, pueden existir muchos tipos. A este respecto hay muchos puntos de vista y no parece haber una estandarización de la norma, debido al carácter subjetivo que pueda tener el test en cuestión y sobre todo que muchas veces puede abarcar o enmarcarse en más de un tipo concreto. Pero, de manera general, y dependiendo del enfoque, estos son algunos de los tipos que se pueden distinguir:

Si no requieren ejecución o sí de la aplicación:
1. Pruebas estáticas.
2. Pruebas dinámicas

Por el tipo de ejecución:
1. Test manuales.
2. Test automáticos.

Por el tipo de visibilidad del test:
1. Test de caja blanca.
2. Test de caja negra.

Por la potestad del test:
1. Test de desarrollador.
2. Test de cliente.

Si queréis saber más sobre tipos de test, en esta página listan hasta 100 diferentes tipos:
http://www.guru99.com/types-of-software-testing.html

Tipos de test habituales TDD

Desde la comunidad de TDD se suele hablar desde el punto de vista de la potestad del test. Es decir, si este pertenece al lado del cliente o del desarrollador.

Los test que pertenecen al Dueño del Producto se llaman test de cliente o de aceptación. Esto no indica que estos test se escriban al final de la vida de la implementación, al contrario, se escriben al principio, ya que la filosofía es partir de estos, que son test que cumplen historias de usuario y que, en base a estos, se vayan generando los demás necesarios que formarían parte del lado del desarrollador.

Esta metodología también se puede llamar (ATDD), que significa desarrollo dirigido a test de aceptación. Estos tipos de test además sirven para validar con el cliente ciertas funcionalidades y darlas por correctas si su resultado es positivo.

Test de Aceptación/Cliente
Es un test que permite comprobar si el software cumple con un requisito de negocio.

Test Funcionales

Todos los test son en realidad funcionales. No obstante, cuando se habla del aspecto funcional nos estamos refiriendo a un subconjunto de los test de aceptación. Los test de aceptación tienen un ámbito mayor porque hay requisitos de negocio que hablan de tiempos de respuesta, de capacidad de carga que van más allá de la funcionalidad.

Test de Sistema
Son los que integran varias partes del sistema, un test del sistema se ejecuta tal cual lo haría un usuario humano. Va desde la interfaz hasta el guardado de la base de datos. Para ello, existen herramientas que permiten automatizar acciones sobre la interfaz del usuario, que puede ser un navegador, tales como Selenium.

Estos tipos de test suelen ser muy frágiles y no conviene depender mucho de ellos, ya que cualquier cambio en la aplicación puede hacer que fallen.

Test Unitarios
Son los test más importantes de la aplicación y comprueban funcionalidades básicas y elementales de la misma. Todo test unitario debe ser :

1. Atómico: que solo comprueba una funcionalidad.
2. Independiente: que no dependa de otros.
3. Inocuo: que no altere el comportamiento de la aplicación después de su ejecución.
4. Rápido: como son muchos, se necesita que sean lo más rápido posible, ya que la idea es ejecutarlos varias veces.

Esto coincide con el principio FIRST (Fast, Independent, Repeatable, Small y Transparent).

Test de Integración
Los test de integración están de camino entre los test del sistema y los unitarios. Su idea es unir varias partes del sistema y para ellos pueden usar dependencias, usar datos reales o alterar datos, pero siempre y cuando dejen el estado de la aplicación tal y como estaba antes de ejecutar el test.

Para terminar, solo decir que esto es una breve introducción al desarrollo dirigido a test. Hay una gran cantidad de información y, sobre todo, un sinfín de opiniones. Cada uno tiene que buscar el equilibrio en base a sus necesidades o a sus ganas de mejorar. Desde mi punto de vista, programar con test es positivo y hace que el software adquiera un grado más de fiabilidad y de calidad.

Fuentes
Wikipedia
Diseño Ágil con TDD de Carlos Blé Jurado