Hablemos un poco como en una mesa redonda sobre "El futuro de la prueba de unidad". La mayor parte de la conversación se centró en el mocking. Se trata de un consenso general que los frameworks de mock se están utilizando en forma muy mayoritaria.
La teoría es la siguiente. A menudo, implementar todas las interfaces necesarias es muy tedioso y consume mucho tiempo. Entonces, para tornar las cosas más fáciles, la gente está apelando a los frameworks de mocking. Eso sólo oculta el problema de raíz, que es un API muy compleja.
Un tema popular es la diferencia entre "prueba de desarrolladores" y la prueba que no todo el mundo hace. La idea de que los desarrolladores escriben solamente pruebas unitarias es frecuente durante los debates. Probar en conformidad con los requisitos, las pruebas de aceptación, las pruebas de integración y todas las demás formas de las pruebas son problemas de alguien fuera del desarrollo.
Eso resalta un malentendido en la comunidad de pruebas unitarias. Especialmente, la suposición de que todos los desarrolladores tienen un equipo de control de calidad (QA) para cuidar de todos los demás tipos de prueba. Lamentablemente, incluso en las empresas multimillonarias no suelen disponer de un equipo de control de calidad, dejando toda la prueba en masnos del desarrollador y el usuario final.
La principal excusa para no soportar más tipos de pruebas fue la velocidad. Las pruebas unitarias ya son lentas y, por tanto, no hay lugar para la realización de pruebas mas lentas que incluyen la comunicación a través de la red. Peor aún es el hecho de que ninguna otra opción se consideró.
Por ejemplo, la pruebas unitarias pueden ser inteligentes. Puede utilizar el resultado de la cobertura de código para ejecutar las pruebas sólo para el código que han cambiado. Cambiar una clase no debería requerir que se ejecute todo el conjunto de pruebas. El término "prueba unitaria" significa que usted puede probar sólo una pequeña pieza.
Otra posibilidad que no se ha discutido es la palanca de la programación distribuida. El código y las pruebas pueden ser rápidamente subidos a varios servidores y ejecutadas en ellos. Ya tenemos toda la tecnología necesaria para la aplicación de la integración contínua.
Muchos, reconocemos que las bases de datos están siendo descuidadas. La mayoría de los desarrolladores de base de datos tiene poco o ningún concepto de pruebas unitarias y hay muy pocas herramientas para soportarlas. Y podemos decir que no hay muchos grupos que ofrezcan opciones reales para hacer frente a los problemas sociales.
En el lado positivo, hay debates acerca del uso de herramientas de modelación para hacer más fácil las pruebas unitarias. Hay muchas opciones aquí y como empezar en el nivel de contratos. Los contratos pueden ser utilizados por los generadores de código para escribir las pruebass. Obviamente, esto no sería una solución 100%, sino que reduciría la carga de escenarios comunes.
Otra idea que era prometedora es, que la mayoría de las personas asumen que una prueba de cuentas comienza en $100 y después de la operación es sólo $80. La alternativa es primero ver el saldo actual ($100) y, a continuación, comprobar si hubo una reducción de $20. Por lo tanto, una completa reconfiguración del ambiente de prueba NO es necesaria para cada ejecución.
Muchos seguimos TDD como metodología principal para los desarrollos, sabiendo que nos da calidad, seguridad ante cambios y sobre todo muchos mejores diseños de las soluciones. Habría que ver como podemos mejorar el tiempo de desarrollo, juntando TDD con lo dicho anteriormente, y así poder hacer mas ameno el hecho de hacer pruebas unitarias, de componentes y de integración en los desarrollos que hacemos todos los días.
