Mes: junio 2020

Medición de cobertura en .Net Core con Coverlet

Luego de cumplir con los primeros hitos de negocio y teniendo un equipo que empieza a estabilizarse me puse a hacer algunas pruebas para medir la cobertura de nuestro proyecto.

En primera instancia atiné a utilizar OpenCover, una herramienta que había utilizado en proyectos anteriores, pero me encontré que solo corre en Windows. Nuestra infraestructura de build corre en Linux y yo particularmente trabajo en MacOS. Con lo cual OpenCover quedó descartado.

Luego de Googlear un poco dí con Coverlet que según la documentación es multiplataforma. Investigando un poco más encontré este artículo de Scott Hanselman y con eso me bastó para hacer una prueba. A continuación voy a compartir algunos descubrimiento que hice aprendiendo a utilizar esta herramienta.

En primer lugar tenemos que saber que hay tres formas de utilizar esta Coverlet:

  1. Como una extensión de dotnet-cli
  2. Como un collector integrado al motor de ejecución de VSTest
  3. Como una tarea de MSBuild

Yo decidí ir por esta última estrategia. Para ello el primer paso es agregar el paquete coverlet.msbuild a cada uno de los proyectos de tests. Una vez agregado este paquete simplemente tenemos que agregar el parámetro de cobertura al momento de la ejecución de los tests

dotnet add package coverlet.msbuild
dotnet test /p:CollectCoverage=true

Si tenemos un solo proyecto de tests que cubre todos los proyectos/assemblies de nuestra solución, con esto ya habrá sido suficiente. Al ejecutar los comandos anteriores obtendremos una salida como la que se muestra en la siguiente figura.

Pero si nuestra solución, como es muy habitual, tiene varios proyectos de tests nos vamos a encontrar que la medición que hace Coverlet es «parcial»/»desagregada». Ocurre que cada proyecto de tests es ejecutado ejecutado independientemente haciendo que la medición de cobertura también sea independiente lo cual a su vez hace que tengamos varios reportes de cobertura. Esto se puede observar en la siguiente figura.

El primer reporte corresponde al proyecto de tests de Domain y nos indica que precisamente Domain tiene una cobertura de ~79%.
El segundo reporte corresponde al proyecto de tests de ApiServices y como ApiServices depende de Domain, la medición de cobertura considera ambos proyectos. Pero dado que los tests de ApiServices apenas tocan el código de Domain, la cobertura informada sobre Domain es mínima (~6%). Entonces lo que deberíamos hacer para obtener el valor correcto de cobertura es mezclar el reporte de cobertura generado por el proyecto de tests de Domain y el proyecto de tests de ApiServices. Aquí también coverlet nos da varias opciones. En mi caso, lo que hice fue ejecutar explícitamente cada proyecto de test por separado, escribiendo los resultados en un archivo y en la misma ejecución indicándole a Coverlet que realice el merge con el archivo de cobertura de la ejecución anterior.

dotnet test Domain.Tests/Domain.Tests.csproj /p:CollectCoverage=true /p:CoverletOutput=../coverage.json

dotnet test ApiServices.Tests/ApiServices.Tests.csproj /p:CollectCoverage=true /p:CoverletOutput=../coverage.json /p:MergeWith=../coverage.json

De esta forma el reporte se genera correctamente.

Una situación habitual cuando medimos la cobertura es no incluir en el cálculo algunas archivos. En nuestro caso ocurre que consumimos servicios SOAP, y utilizamos una herramienta que nos genera un conjunto de clases proxy para interactuar con SOAP. Dichas clases son almacenadas en un archivo Reference.cs que queremos excluir del análisis de cobertura. Para esto debemos incluir un parámetro adicional para Coverlet en la ejecución de los test /p:ExcludeByFile=»**/Reference.cs».

Bien, con todo lo descripto hasta el momento hemos logrado medir el % de cobertura de nuestro código. Lo siguiente que suele hacerse es ver cuales son las partes de código sin cobertura. Si bien coverlet tiene la capacidad de detectar esto, no provee un mecanismo cómodo para visualizarlo y por ello debemos utilizar otra herramienta complementaria. Pero eso será parte de otro post.

Sobre la secuencia de tests al hacer TDD

Este es uno de los temas clave al hacer TDD. La elección de la secuencia de test puede hacer que el ciclo de TDD resulte muy fluido o que sea una pesadilla. Más aún, tengo la sospecha que la elección inapropiada de la secuencia de tests debe ser una de las principales razones de abandono de TDD. Personalmente suelo aplicar la heurística conocida como «TDD Guided by Zombies» propuesta por James Grenning, pero incluso usando esa heurística hay situaciones en la que mi secuencia de tests no me resulta lo suficientemente fluida. Quiero compartir un caso concreto para repasar distintas heurísticas.

Ayer por la tarde estábamos con otros 3 colegas en un sesión de mobbing trabajando sobre una funcionalidad que consistía en filtrar una lista de objetos Cuenta en base a 4 condiciones. En caso de no encontrar ningún objeto que cumpla con las 4 condiciones en forma simultánea debíamos generar un error pues eso representaba una situación excepcional de negocio.

Un colega propuso comenzar por los casos de excepción y luego los casos positivos. Lo que me gusta de esta heurística es que inicialmente permite avanzar rápido, el código del método generado comienza con una secuencia de validaciones que van respondiendo a los distintos casos de excepción. Lo que no gusta de esta secuencia es que durante varios ciclos el código no resuelve el problema para nadie, o sea, el método en cuestión solo valida y lanza excepciones pero no genera una lista filtrada. Hay que esperar casi hasta el final de la secuencia para obtener una lista filtrada. Una posible secuencia de tests con esta estrategia sería:

DeberiaLanzarExcepcionSiNoTieneCuentasEnPesos
DeberiaLanzarExcepcionSiNoTieneCuentasConTarjetaAsociada
DeberiaLanzarExcepcionSiNoTieneCuentasTitular
DeberiaLanzarExcepcionSiNoTieneCuentasActivas
DeberiaFiltrarLasCuentasEnPesosConTarjetaTitularidadActivas
...(otros casos positivos)...

Personalmente yo prefiero comenzar con casos positivos y dejar las situaciones de excepción para el final. En este sentido un camino posible sería arrancar literalmente al revés del ejemplo anterior, comenzando con el caso positivo que contempla todas las condiciones. El problema de esta estrategia es que genera un paso muy grande, o sea, implica escribir en un solo paso el algoritmo completo que considera las 4 condiciones.

Otra opción en línea con la idea de transitar el camino de casos positivos y siguiendo la heurística de Zombies, es arrancar con una condición positiva a la vez. De esta forma, ya de entrada estamos generando una lista filtrada, que al menos para algunos casos será una lista completamente válida. A partir de eso podemos ir generar nuevos casos positivos refinando el filtro y agregando los casos de excepción luego de tener todo el filtro completo. De esta forma cada paso del ciclo se mantiene pequeño y el algoritmo de filtrado se construye incrementalmente. La secuencia resultante podría ser:

DeberiaFiltrarSoloCuentasEnPesos
DeberiaFiltrarSoloCuentasConTarjeAsociada
DeberiaFiltrarSoloCuentasTitular
DeberiaFiltrarSoloCuentasActivas
.... (otros casos incluyendo los de excepcion)....

Obviamente que también está la posibilidad de tomar una secuencia que alterne casos positivos y negativos. De hecho si uno siguiera a raja tabla la heurística Zombie el primer caso (caso Zero) sería negativo y los siguientes positivos (caso One y casos Many).

Bueno, esto esto por ahora pero creo que este tema de la elección de la secuencia de tests aún da para mucha charla.

The Pragmatic Programmer

La primera edición de este libro fue publicada en 1999 pero yo no lo conocí hasta ~2005. Y no lo leí hasta 2009 cuando lo encontré la biblioteca de la empresa en la que trabajaba en aquella época. El año pasado se publicó la edición 20 aniversario y no dudé en comprarlo. Ayer terminé de leerlo.

Mas allá de la elegancia de la edición tapa dura, a nivel contenido el libro no tiene desperdicio y creo que es una lectura obligada para todo developer. Cubre temas muy variados que van desde principios de diseño, estimación, hasta ética profesional pasando por programación concurrente, técnicas de testing y recomendaciones de organizacional personal.

Complementariamente a la usual división en capítulos, el libro está organizado en «temas» (topics) que son subdivisiones de los capítulos y la extensión de cada uno es tal que su lectura puede realizarse en 30 minutos (lo cual a mi personalmente me facilita mucho la lectura). Asimismo al final de cada tema se listan los temas relacionados y se ofrece una serie de ejercicios, algunos de reflexión, otros de programación, etc.

Los autores son Dave Thomas y Andrew Hunt, ambos autores del Agile Manifesto. Tal vez por eso muchas de las cuestiones tratadas en el libro están abordadas desde una perspectiva ágil.

Esta edición 20 aniversario es bastante distinta a la edición original de 1999. La esencia de libro es la misma pero el contenido ha sido totalmente actualizado. De hecho los propios autores reconocen que hay partes del libro que fueron completamente reescritas.

Notes from my session @XPConf 2020

Last Friday I delivered my session «BDD your solution from git init to Kubernetes» in the context of the XP Conf 2020. This was my forth participation in the XP Conference, but as you can image this time I didn’t travel anywhere, the conference turned to an online format.

In my experience most of the BDD/TDD sessions/trainings are based on «toy examples» focused just on coding and leaving apart the whole CI/CD cycle. One of the goals of my session was to share with the participants a hands-on, real-world experience applying BDD/TDD in the context of the CI/CD pipeline. For this I setup a Kubernetes cluster on Digital Ocean and we used the Gitlab platform to implement the pipeline.

I am very satisfied with the flow and the result of the session. The evaluation of the participants was (average) 4.6 / 5.

The code is available on GitLab and slides are available here.

Algunas reflexiones luego de cinco meses con .Net Core

En enero comencé a trabajar un en proyecto para el sector financiero utilizando .Net Core y me parece que este es un buen momento para compartir algunas sensaciones y hallazgos.

Antes que nada debo decir que hasta 2009 mi carrera profesional estuvo muy vinculada a tecnología Microsoft en general y a .Net en particular. En 2009 di un vuelco en mi carrera y empecé a involucrarme más de cerca con otras tecnologías. Fue así que hice varios proyectos con Java y Ruby y algunos otros más escasos con NodeJS, Python y C++. Este transitar por variadas tecnologías me resultó muy enriquecedor y revelador. Entre otras cosas descubrí que es posible desarrollar software sin estar completamente atado a un IDE particular y a la infraestructura. Tradicionalmente en .Net uno «vivía» atado a Visual Studio y al Internet Information Server.

Ahora sí, hablemos de .Net Core. Quiero referirme en particular a tres puntos: Experiencia del desarrollador, Stack de herramientas e Infraestructura.

Experiencia del desarrollador

El primer punto a destacar aquí es el desarrollo multiplataforma, .Net core está disponible para Windows, Linux y MacOS (justamente en mi equipo tenemos gente trabajando en las 3 plataformas). [1]

El otro punto destacable es la posibilidad trabajar con .Net Core desde la línea de comandos a partir de un CLI que ofrece funcionalidades de scaffolding, ejecución de tests y posibilidades de extensión. Hay que decir que si bien es posible hacer muchas operaciones desde la línea de comando, no todas están lo suficiente documentadas y como dicen algunos miembros de mi equipo: «hay que aprender los conjuros».

Estos dos puntos hacen que la experiencia de desarrollar con .Net Core sea mucho más parecida a la experiencia del desarrollar con NodeJS, Ruby o Python.

Finalmente hay que destacar las nuevas interfaces de Asp.Net Core que posibilitan el desarrollo de aplicaciones más testeables y el uso de TDD de punta a punta.

Stack de herramientas

Si bien siempre me gusto C# como lenguaje el stack de herramientas me parecía muy limitado, sobre todo luego de trabajar en Ruby. Tradicionalmente el desarrollo a nivel profesional con .Net obligaba al uso de Visual Studio. Hoy en día con .Net Core existen varias alternativas al tradicional Visual Studio, muchas de ellas desarrolladas/soportadas por la iniciativa Omnisharp y entre las que se destacan varios «IDEs livianos» como VSCode, Sublime y Atom. El propio Microsoft viene dando mucho impulso a VSCode el cual tiene una particularidad que lo destaca por encima del resto de los IDEs de su categoría: la capacidad de debugging. Dado que .Net Core aún no ofrece un debugger de línea de comandos el hecho de que el IDE ofrezca un debugger es un punto relevante.

Personalmente intenté trabajar con VSCode y no me resultó cómodo, pero debo destacar que varios miembros de mi equipo (los que viven en Linux) lo vienen utilizando y están conformes.

La herramienta que yo vengo utilizando es Rider, el IDE multiplataforma para desarrollo .Net que perteneciente a la familia de IDEs de JetBrains. Este hecho es una de las cosas que me inclinó a usar Rider ya que en los últimos años yo venía utilizando IntelliJ (Java) y RubyMine (Ruby). Las tres herramientas son muy parecidas y a mi parecer excelentes.

Infraestructura

El hecho de ser multiplataforma despegó completamente a .Net Core (o más precisamente a Asp.net Core) del Internet Information Server. Aquí es donde aparece Kestrel, el web server multiplaforma de Asp.Net Core. Una particularidad de Kestrel es que puede ser instanciado vía código dentro de cualquier aplicación .Net Core. Esto mejora mucho la experiencia desarrollo, testeabilidad de las aplicaciones web y el empaquetamiento/distribución de aplicaciones Asp.Net Core. En relación a este último punto hay mucha información y recursos respecto a distribuir aplicación Asp.Net Core con Docker, de hecho hay imágenes Docker de Net Core y Asp.Net oficiales provistas por Microsoft.

En nuestro proyecto estamos usando Docker y nuestra aplicación corre Dockerizada dentro de Kubernetes.

[1] Hay que mencionar que previo a .Net Core hubo varios iniciativas (Mono, Xamarin, etc) para proveer algunas de las caraterísticas que menciono en este artículo, pero a mi parecer dichas iniciativas no lograron no llegaron al mainstream, aunque sin duda fueron motivadores del nacimiento de .Net Core.