From UnitTests to FirstRuns
Ya sabeis (los que me conoceis, o me seguís en este blog) que he sido un defensor y casi fan-atico de las pruebas unitarias desde hace muchos años. Antes incluso de que VisualStudio empezase a incluir TestMethods. Incluso tengo alguna herramienta publicada como https://trx2html.codeplex.com para generar informes basados en las pruebas untarias.
Antes de continuar conviene recordar que entendemos por pruebas unitarias
- TestMethods que ejecutan y validan una única funcinoalidad ( para lo cual suele ser necesario usar Mocks, Stubs y/o Fakes). Patrón Arrange/Act/Assert
- Se ejecutan constantenmente por todos los desarrolladores y en el servidor de Builds. Por lo que es necesario que sean independientes del orden en que se ejcutan, y sobre todo repetibles.
- Se mantienen y evolucionan a la par que el código de producción.
Sin embargo, a veces, las pruebas unitarias no son la mejor solución, y en vez de acelerar el desarrollo, o mejorar la calidad del código, tienen un efecto perverso, haciendo que el desarrollo se realentice, y la compresión se complique. Con esto no quiero decir que las pruebas unitarias esten mal, tan sólo que hay otros tipos de pruebas, que sin ser unitarias, pueden ser mucho más efectivas.
De hecho, en el proyecto que tengo entre manos, tomamos una decisión hace unos meses que de momento está funcionando muy bien: Pasar de UnitTests a FirstRuns.
En este caso, no tratábamos de UnitTests puros, ya que dependian de la base de datos, y dada la naturaleza del proyecto, una migración de COBOL, no era posible aplicar ningún patrón que nos permitiese desacoplar las pruebas unitarias de la base de datos, por lo que el conjunto de pruebas que ejecutaban el COBOL dependendian de datos que ibamos actualizando en la base de datos. A estos conjuntos de datos los denominábamos "escenarios", pero rápidamente estos escenarios se fueron haciendo más y más complejos. hasta tal punto que gastábamos más tiempo en el escenario de pruebas que en el código a migrar, o sus pruebas.
Por tanto decidimos abandonar esta línea, pero necesitábamos algo que nos permitiese ejecutar, por lo menos una primera vez, el cóidgo que migrábamos antes de hacer checkIn. Y aparecieron las pruebas tipo FirstRuns:
Estas pruebas siguen siendo TestMethods que se usan durante el desarrollo para poder ejecutar partes del código, pero sin requerir que puedan ejecutarse repetidamente, ni que se tenga que mantener el escenario de datos de que dependen. Por tanto no entran a formar parte de la Build, y probablemente no hagan un Asserts muy específicos.
Pero como decia antes, sirven como puntos de entrada de las diferentes partes de una aplicación, y también se pueden usar para agilizar la corrección de Bugs.