“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!

Como habíamos prometido, daremos inicio con este post a la serie de publicaciones con las que intentaremos mostrar de qué manera se puede incrementar la calidad del software que nuestra empresa produce, mejorando el proceso de testing en las diferentes formas que toma a lo largo del ciclo de vida de la aplicación.

Tipos de testing vs. herramientas de testing

En las primeras etapas del ciclo de vida de la aplicación, en aquellas donde se comienzan a implementar mayormente requerimientos no funcionales (APIs, frameworks, etc.), se requiere de un tipo de tester especializado, con altos conocimientos de programación, que genere casos de pruebas unitarias con un alto grado de automatización (cuando digo alto apunto al 100% de automatización)

A medida que las iteraciones avanzan y se empiezan a obtener las primeras piezas funcionales, aparece la necesidad de un testing totalmente diferente, opuesto, donde el tester necesita altos conocimientos del proceso de negocio y pocos o nulos conocimientos de programación.

Si trazáramos una línea, podríamos decir entonces que tenemos en una punta un testing de tipo “especializado”, con mayoría de casos de test automatizados construidos por expertos en programación, y en la otra punta un testing más “generalista” con gran cantidad de casos de test manuales a cargo de especialistas en el negocio en cuestión, con toda una escala de grises en el medio.

Según algunos estudios, se indica que la mayoría de las herramientas de apoyo al testing apuntan a la parte “especialista”, siendo que el grueso del esfuerzo que realiza la empresa se ubica en la parte “generalista”

VSTS 2010 como solución ALM ante la problemática del testing

Con este enfoque como guía, iremos mostrando en sucesivas entregas, de qué manera VSTS 2010 contribuye a la mejora del proceso de testing en todo el espectro.

Comenzaremos mostrando las herramientas que propone la solución de MS desde el extremo más especialista, hasta llegar al punto opuesto, abarcando los siguientes tópicos:

• Testing unitario y las mejoras para aplicación de técnicas de TDD (Test Driven Development)
• Intellitrace
• Coded UI Test
• Lab Management
• Integración Continua

Hasta la próxima !

En uno de los servidores con los que estamos trabajando, tuvimos problemas luego de la instalación del Service Pack 1 de Team Foundation Server 2010.

Era uno de esos servidores prolijitos, instalados desde cero, nada de migraciones raras ni parches extraños.

Luego de una instalación exitosa del SP1, los servicios parecían funcionar bien pero la Project Collection empezó dar error de acceso y se empezaron a encolar tareas sin pudieran completarse (ver Consola de Administración de TFS –> Team Project Collections –> Solapa “Status”).

Después de investigar un buen rato, resultó que uno de los nuevos servicios que trae la versión 2010 conocido como TFSJobAgent no podía iniciar por un problema de logon (primer indicio, alguien recordó que el usuario con el que se instalaron el SP1 había cambiado su password luego de la instalación inicial del servidor pero antes de la instalación del SP1).

Sabiendo esto, actualizamos las credenciales de las cuentas desde la misma consola pero el servicio seguía sin levantar. Por otra parte, ¿donde está ese servicio?. Si no hubiera leído esto no hubiera sabido que el nombre real es “Visual Studio Team Foundation Background Job Agent”. En algún momento tuvimos la necesidad de detenerlo, pero lo hicimos usando el comando “net stop tfsjobagent”.

Cambiando las credenciales con las que se inicia ese servicio por las nuevas, todo volvió a funcionar con debía. Por algún motivo, no se habían actualizado justo en ese punto.

Saludos !

En la búsqueda diaria de la solución absoluta y definitiva a los problemas de gestión del código fuente, di con un post de El Bruno donde plantea algo muy simple pero efectivo:

1. Formación

    1.1 Conocer las capacidades de la herramienta

    1.2 Conocer la problemática del negocio

2. Tomar una decisión para comenzar a trabajar

3. Cada 6 semanas/meses ajustar la forma de trabajo

4. Goto 2

Según El Bruno, esto surge como conclusión de una Mesa Redonda con la gente de MadridDotNet donde se compartieron experiencias de administración de código fuente en cuestiones de branching, merge, archivos históricos, la maldición del checkout exclusivo y otras cuestiones.

Recomiendo su lectura, es un post cortito y ameno.

Hasta la próxima !

Ya van quedando cada vez menos excusas para no estar entrenado con lo último. Acaba de salir publicado un Training Kit gratuito para VS 2010 y .NET 4.0.

Es un download de un poco más de 400MB que en disco se transforman en casi 2GB de presentaciones, papers, hand-on-labs, código de ejemplo, etc.

Pueden descargarlo desde aquí.

Enjoy !

Estamos preparando una serie de post dedicados a testing con VSTS 2010 en las diferentes variantes en que se presenta a lo largo del ciclo de vida de la aplicación, y para ir introduciendo el tema quisiera dejarles unos links para que tengan a mano.

Se trata del blog de Mathew Aniyan, PM de Microsoft. En su blog, Mathew ha estado publicando una serie de Tips relacionado a lo que se conoce como Coded UI Test (Pruebas programáticas de Interfaz de Usuario).

Al momento de publicar este post, llegó hasta el N° 8, posteado con fecha enero/2010. Esperamos que retome la iniciativa y siga publicando más trucos.

Pueden ver la serie de tips aquí.

Saludos !

En realidad este error lo obtuvimos inicialmente al intentar encolar una build en un proyecto recientemente “trasplantado” desde otro servidor. Obviamente en el servidor de origen no había problemas.

Como era muy escasa la información registrada en los diferentes logs, investigamos un poco y nos dimos cuenta que el error ocurría cuando el build server intentaba descargar la propia definición del build (basada en el DefaultTemplate.xml) para hacer su trabajo. Podíamos obtener ese mismo error desde Visual Studio intentando descargar cualquier otro template de la carpeta BuildProcessTemplates del Source Control.

Sabiendo que no era un tema del build server sino algo más genérico, volvimos a buscar y apareció la solución. Hay que seguir estos pasos:

• Detener IIS
• Borrar la caché local del servidor TFS (buscar en C:\Program Files\Microsoft Team Foundation Server 2010\Application Tier\Web Services\_tfs_data)
• Reiniciar IIS

Voilà !!

Hasta la próxima !!

Hace unos días publiqué un post donde mencionaba los recaudos mínimos que deberíamos considerar al momento de instalar algún Add-on para TFS (vale también para VS).

Como no quiero que me consideren “apocalíptico” ni mucho menos trataré, por un lado, de mostrar las herramientas que nosotros hemos instalado y utilizado largamente y que nos han facilitado la vida en muchas oportunidades (o que estamos testeando con TFS 2010). Por el otro, me gustaría que ustedes comenten acerca de las experiencias que han tenido para que este post sirva, de alguna manera, como referencia de las herramientas que todo administrador o usuario de TFS debiera tener en su toolkit.

Empiezo yo:

Administración General

• Team Foundation Server Tools 2010: Un viejo conocido, en su versión para TFS 2010, que entre otras cosas incluye:
  • Alerts Explorer: UI gráfica que permite suscribirse a los diferentes eventos del servidor (cambio de un work-item, build terminado, nuevo check-in, etc.)
  • TFS Backups: administra un schedule para backups de la base de datos de configuración, de los proyectos de la colección, sharepoint (si se instaló con la integración de esa herramienta), reporting services (ídem)
  • Best Practices Analyzer: Verifica problemas de deploy, data usage, etc.
  • Pack de políticas de check-in
  • Mejoras para Team Explorer
  • Editor de Templates
• Team Foundation Sidekicks: Excelente herramienta de Attrice que permite visualizar/administrar entre otras cosas:
  • Historial de archivos del Source Control
  • Status (cheched out, locks, etc.)
  • Workspaces
  • Labels
  • Etc.

Seguridad

• Team Foundation Server Administration Tool: Uno de los problemas recurrentes al administrar proyectos de TFS es el de configurar permisos de usuarios. Hay que administrar seguridad tanto en el servidor TFS, el servidor de reportes y el sitio Sharepoint, cada uno con sus particularidades. Esta herramienta permitirá hacerlo todo junto desde un mismo lugar

Templates

• Microsoft Visual Studio Scrum 1.0: Uno de los templates más esperados.
• Scrum for Team System (antes conocido como Conchango): Excelente template Scrum, ahora en su versión para TFS 2010
• TMap for VS 2010: Un template para proceso de testing desarrollado por Sogeti en colaboración con MS

Visual Studio

• Productivity Power Tools (no es puramente TFS, pero los programadores –y otros- agradecidos) 
  • Solution Navigator: Permite ver clases (y sus miembros) desde el Solution Explorer, con filtros para visualizar solamente archivos abiertos, sin grabar, etc., vistas previas, y más.
  • Tab Well UI: Permite más posibilidades de manejo de ventanas del IDE para uso con múltiples monitores, tabs fijos (para que no desaparezcan cuando hay muchos documentos abiertos), coloreo de tabs según ciertas condiciones (soporta expresiones regulares), etc.
  • Searchable Add Reference Dialog: Ahora podemos hacer búsquedas al agregar referencias a nuestro proyecto !
  • Y mucho más …

Otros

• Team Foundation Server MSSCCI Provider 2010: Permite acceso al Version Control de TFS a herramientas que no soportan integración con Team Explorer, por ejemplo:
  • Visual Studio 2003
  • Visual Foxpro 9 SP2
  • Microsoft Access 2007
  • Powerbuilder 11.5
  • Enterprise Architect 7.5
  • y otros …
• VS Team Explorer Everywhere 2010: Permite acceso a TFS de cualquier IDE basada en Eclipse.

Creo que tengo alguna otra más para compartir, pero les dejo la posta a Uds. …

Saludos !

Me acabo de cruzar con un post de la gente de Urban Turtle, que me pareció muy interesante.

Habla de herramientas de terceras partes que extienden la funcionalidad de TFS.

Es cada vez mayor la cantidad de herramientas que aparecen en la web que se valen de la extensibilidad que brinda TFS y que proponen complementar y/o optimizar los diferentes aspectos que cubre la solución ALM de MS (además, no sería loco pensar que esta tendencia se vaya acentuando con cada nueva versión de la plataforma).

Si bien esto supone un gran beneficio, aunque más no sea por la cantidad y variedad de la oferta, me pareció interesante difundir algunos de los cuidados que según Mario Cardinal (y quien suscribe) deberíamos tener al momento de elegir alguna de estas herramientas. Todo esto sin mencionar cuestiones de costos por licenciamiento, sólo enfocándonos en cuestiones más bien técnicas.

Antes de que sigan leyendo vale una aclaración. Yo sé que muchos van a pensar que la mayoría de estas cuestiones son más que obvias, pero también sé que ante alguna necesidad concreta de esas que queman, no tenemos demasiado tiempo para andar pensando a mediano o largo plazo y se vuelve muy tentador instalar alguna solución para salir rápidamente del escollo.

Propongo que nos detengamos un minuto y hagamos una checklist que incluya, al menos, alguno de estos puntos:

Soporte

• Qué tipo de soporte se ofrece?
• Cuándo fue publicada la última versión? Cada cuanto se publican? Sigue en Beta?
• Está disponible el código fuente?

Evolución de la plataforma ALM

• Será fácil migrar cuando aparezca la próxima versión de TFS? (aquel que pueda responder este tipo de preguntas rápidamente, que por favor se contacte por privado porque necesito que me preste la bola de cristal por algunos días)

Relación con el servidor TFS

• Modifica el esquema de Base de Datos de TFS?
• Requiere modificación de los templates de proyectos ya creados?
• Tengo varios proyectos creados con diferentes templates, alguno de ellos personalizado. Se adapta a todos los proyectos?.
• Y a todos los tipos de Work Item?
• Tengo varios proyectos, en diferentes versiones de TFS. Aplica a todas las versiones?
• Qué impacto tiene el hecho de que esa herramienta no aplique para todos mis proyectos y/o versiones de TFS?
• Qué pasa con el Data Warehouse y con los reportes ?
• Los que ya están van a seguir funcionando?

Deployment y mantenibilidad

• Sirve para cualquier proyecto que ya esté en marcha o sólo para nuevos proyectos?
• Requiere instalar algún componente en los clientes?
• Qué tan compleja es esta instalación?
• Qué tipo de desarrollos soporta (Winform, Web, WPF, etc.) ?

Localization

• Es compatible con la configuración de mi servidor TFS?
• Y con la configuración de Collation de mi SQL Server?

Verifiquemos por favor que en lugar de encontrar una solución no estemos encontrando un nuevo problema.

Saludos !

Recientemente, un cliente nos comenta la decisión de incorporar TFS en la empresa como solución ALM.

El desafío que se planteaba era interesante, tenían un proceso medianamente ordenado pero cada uno de los roles involucrados utilizaba sus propias herramientas (algunas de ellas manuales) para administrar los documentos que se generaban, por lo que además de la diversidad de formatos, no existía sincronización entre esos documentos. Mucho menos pensar en algún tipo de versionamiento o workflow de aprobación.

Por su parte, el equipo de desarrollo recibía quejas constantes originadas en el cliente/usuario que apuntaban a la baja calidad del producto entregado. ¿Cómo era esto posible si el equipo contaba con recursos altamente capacitados?. Claramente el problema venía del lado de la mala administración del código fuente.

Con estas limitaciones en la gestión de los diferentes proyectos quedaba claro que no se podía contar con casi ningún tipo de métrica, gráfico o reporte que mostrara el grado de avance (o retroceso…). Tampoco existía la posibilidad de obtener algún indicador que permitiera la detección temprana de desviaciones.

Si bien la decisión estaba tomada, se reconocía asimismo la existencia de algún temor ante la imposibilidad de adaptarse a esta nueva herramienta que se presentaba como un gigante indomable frente a aquellas otras a las que conocían desde hace mucho tiempo. Iríamos por una cambio gradual.

En resumen, se requería una incorporación gradual de TFS al proceso de la empresa, pero con una visión de mediano/largo plazo que escale correctamente a medida que se vayan obteniendo resultados y que se vayan incorporando otras áreas y recursos de la empresa a esta nueva forma de integración. Por lo tanto, teníamos que lograr resultados rápidamente para convencer a los grupos más escépticos y a la vez estar preparados para cuando éstos decidan subirse al nuevo barco.

Arquitectura de servidores

Estaba claro que tanto las bases de datos (Data Services), como los reportes (Reporting Services, Analysis Services), serían instalados en un servidor dedicado distinto al que se usaría como Application Tier. En caso de detectar problemas de performance originados en el Data Tier, podríamos escalar utilizando SQL Server clusters.

Lo nuevo de todo esto es que con la versión 2010 de TFS también podemos escalar el Application Tier. Aparece aquí el nuevo concepto de TFS Farm.

Con esta nueva posibilidad, podemos agregar un nuevo servidor a nuestra Application Tier si se diera alguna de estas situaciones:

• Necesidad de redundancia en la instalación de TFS
• Necesidad de mejora de performance
• Necesidad de restaurar un servidor que ha fallado
• Necesidad de mover una instalación a otro servidor

Con esta arquitectura obtendríamos estos dos importantes beneficios:

• Soporte de NLB (Network Load Balancing) en Application Tiers: Además de la mejora en performance, obtendremos alta disponibilidad, ya que podría caerse uno de los servidores sin que el usuario se entere. También podríamos aplicar parches individualmente a cada servidor poniéndolo offline sin desconectar a los usuarios.
• Escalabilidad en Data Tiers: Teniendo más de un servidor SQL, tendremos más flexibilidad, ya que como cada Team Project Collection está en una base de datos independiente, podremos hostearlo como mejor nos convenga.

Un tema resuelto.

Organización de los proyectos

Habiendo relevado poco y nada a nivel global, no estaba del todo claro cómo íbamos a organizar los proyectos, y como el cliente no conocía TFS, no podía colaborar demasiado en determinar si usaríamos un sólo Team Project a nivel global y nos manejaríamos con áreas de proyecto para separar sectores (lo que implicaba un trabajo importante de personalización de templates de proyecto) o un Team Project por sector.

Finalmente nos decidimos por esta última opción, ya que si bien no estaba perfectamente delimitado, cada sector de la empresa se dedicaba casi exclusivamente a un sólo producto de software. Con esto, más algunos toques a las queries de work items, podríamos resolver las cuestiones más urgentes y en caso de necesitar un nivel de agrupamiento más alto, tendríamos la posibilidad de armar otras Project Collections.

Otro tema resuelto.

Final abierto (o no tanto …)

Al ser una instalación limpia, fue bastante sencilla y rápida la instalación de los diferentes componentes y la creación del Team Project que utilizaría, inicialmente, el sector que planteó los requerimientos.

Terminada la instalación, y habiendo logrado que los diferentes roles de ese sector pudieran …

… manejar documentos versionados utilizando el Project Portal como punto de acceso y que además, registren requerimientos en un repositorio común,

… que los desarrolladores puedan asociar el código fuente a cada uno de esos nuevos requerimientos y que además tengan la posibilidad de corregir bugs de versiones en producción al mismo tiempo que se desarrollan features de la nueva versión sin que eso implique un riesgo de regresión (gracias a un plan sencillo de branching),

… que se empiecen a generar los primeros reportes de trabajo pendiente y de estado de bugs,

todo esto con una solución (relativamente) sencilla y a la vez escalable, no es difícil imaginar cuál va a ser la reacción de los otros sectores de la empresa.

Hasta la próxima.