“Creating a unit test helps a developer to really consider what needs to be done. Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code.” ExtremeProgramming.org
Un poco de contexto
Como generalmente sucede en todos los ámbitos, una de las cosas más difíciles de conseguir es el equilibrio, y la creación de Tests Unitarios no queda fuera de esta premisa.
Por un lado es imposible negar los beneficios que aporta contar con pruebas automatizadas, pero por otro lado también se hace difícil contradecir a aquellos que argumentan que es muy costoso su mantenimiento ante cambios en los requerimientos.
No es la idea de este post entrar en un debate interminable defendiendo una postura u otra, sólo me limitaré a decir que no somos fanáticos de los extremos y que si bien consideramos que es indispensable contar con un buen set de pruebas unitarias, tampoco perdemos de vista el costo de su mantenimiento y vamos adaptando el modelo según las necesidades y posibilidades.
Antes de ir directamente a la herramienta, repasemos algunas definiciones.
El ABC de las pruebas unitarias
Toda prueba unitaria que se precie de tal, deberá contar sí o sí con las siguientes características:
- Ejecución rápida
- Ambito limitado
- Automatizable y repetible
- Cualquiera puede ejecutarlo
- Independiente
- Alta cobertura de código
El ABC del TDD
En el Desarrollo Guiado por Pruebas (Test-Driven Development – TDD) se dice que no existe ningún motivo para escribir código salvo alguna prueba que esté fallando. Esto obliga (a modo de resumen) a trabajar con un ciclo de vida que incluye los siguientes pasos:
- Ante cada nuevo requerimiento, escribir un test. El test inevitablemente fallará porque no hay código que implemente ese requerimiento todavía.
- Escribir el código que pase el test. Se deben enfocar los recursos a que el test pase, sin preocuparse por cuestiones “superfluas” (.. del tipo “ya que estamos, agrego una sobrecarga que reciba tal parámetro porque probablemente lo necesite más adelante”). Tampoco por la elegancia del código. El único objetivo es que el test pase.
- Refactorizar: Es aquí donde se modifca el código para mejorar cuestiones como mantenibilidad, limpieza de código duplicado, etc., sin afectar obviamente la funcionalidad. Esto se comprueba corriendo sucesivamente las pruebas (aquí se ve el beneficio de pruebas que se puedan ejecutar en poco tiempo).
Entrando ahora sí de lleno en la herramienta, veamos qué nos aporta en este sentido.
Ayudas en la edición de código
Como soporte a la práctica de TDD, Visual Studio 2010 cuenta con algunas funcionalidades orientadas a la mejora en la productividad en este ámbito:
Code Snippets: permiten rápidamente generar clases de test (“testc”) o métodos de test (“testm”)
Al escribirse primero las pruebas, obviamente fallaran las referencias a las clases a testear, pero con la generación automática de código, se facilita la tarea de crear el esqueleto de esas clases:
Intellisense en modo Suggestion: En el modo al que estábamos acostumbrados a usar Intellisense (modo Completion), era fácil agregar una referencia a un tipo o variable existente, pero esto no es muy “TDD Friendly”. En VS2010 existe también el modo Suggestion (se activa con Ctrl+Alt+Space) que muestra, mientras estamos tipiando, un cuadro de texto sobre la lista de tipos sugeridos sin obligarnos a seleccionar ninguno.
Ejecución de pruebas unitarias
En cuanto a la ejecución de las pruebas unitarias, más allá de nuestro objetivo de ver muchos iconitos verdes, una de las metas buscadas es conseguir una alta cobertura de código. De nada sirve tener toda una batería de pruebas unitarias si estamos cubriendo (probando) menos de la mitad del código escrito.
La cobertura de código (Code Coverage) es una métrica importantísima que deberíamos obtener para poder certificar que nuestros casos de prueba están cubriendo la totalidad (o la mayor parte posible) del código de la aplicación.
Para habilitar los reportes de Code Coverage en VS2010 tenemos que modificar el archivo “Local.testsettings” y dentro de la opción “Data and Diagnostics” marcar el check correspondiente a “Code Coverage”
Una vez ejecutadas las pruebas, en la ventana Code Coverage Results, podremos ver los porcentajes de ese indicador y a su vez, en el editor de código, ver resaltadas las líneas afectadas por la prueba.
Posts anteriores de esta serie:
Para ir calentando motores …
Contribuyendo a la mejora de calidad de software
Algunas referencias más:
http://geeks.ms/blogs/adiazmartin/archive/2010/01/12/m-225-s-r-225-pido-con-visual-studio-2010-intellisense-para-tdd.aspx
http://blogs.msdn.com/b/ukvsts/archive/2010/03/17/test-driven-development-with-visual-studio-2010.aspx
Hasta la próxima!