Archivo de la etiqueta: tdd

Kata UpperCounter con Software Craftsmanship Madrid

El pasado martes 5 de agosto tuve la oportunidad de acudir a mi primer meetup de Software Craftsmanship Madrid, en el que se celebaba un coding dojo facilitado por Carlos Ble @carlosble. El objetivo de la sesión era hacer uso de un patrón diseñado por Robert “Uncle Bob” Martin llamado “Transformation Priority Premise” que nos lleva a una programación más genérica y funcional.

Tras sentarnos por parejas y escoger el entorno y el lenguaje de programación (En mi caso, C# con Visual Studio 2013 y XUnit como motor de pruebas) se desveló el objetivo de la kata:

Dada una cadena, devolver, en forma de array, las posiciones de dicha cadena cuyos caracteres sean la letra mayúscula

Ejemplos:
– A: {0}
– bA: {1}
– aBcdE: {1, 4}

Primera iteración, sin restricciones

Para esta primera iteración no teníamos ninguna limitación más allá de intentar resolver la kata. El resultado es el que se muestra en el vídeo:

El código completo, tanto del test como de la implementación se puede ver a continuación:

El enfoque es iterativo, utilizando un bucle para recorrer los caracteres de la cadena y la comprobación es bastante artesanal (a mejorar en la segunda iteración) y además, como teníamos tiempo, pudimos probar las Theories de XUnit, que nos permiten utilizar, en el mismo test, diferentes conjuntos de entrada y esperar diferentes resultados.

Segunda iteración, con restricciones

En esta segunda iteración teníamos una limitación importante: No podíamos asignar variables, ni modificar valores existentes. Esto nos deja sin la posibilidad de usar bucles (ya que vamos actualizando la posición del iterador) y forzando nuestro código a que sea más funcional. El resultado es el que se muestra:

El código completo es el siguiente, con el que intentamos seguir a rajatabla la indicación de no asignar o modificar los valores de las variables. En este caso el tiempo no permitió pasar de unos pocos test, pero se aprecia una diferencia notable por una parte en el test y por otra en el código de implementación:

Como nota adicional, gracias a @DanielRoz0 que me ha estado ayudando con la edición del vídeo, se pudo simplificar la comparación de una letra con su correspondiente mayúscula mediante el uso de la función char.IsUpper(source, index).

Información y enlaces:

Excepciones con Test Unitarios en C#

Una kata, en el contexto de desarrollo de software, es un ejercicio de programación que nos permite, en un entorno controlado, probar nuevas técnicas y mejorar la calidad de nuestro código. Una de las maneras más interesantes de realizarlas es a través de la plataforma Solveet, que, en colaboración con la web 12meses12katas, proponen un ejercicio mensual.

En el ejercicio del pasado mes, descubrí que nunca había probado un método que devolviera una excepción, así que recurrí a lo primero que sabía, un bloque try catch, aunque el resultado deja bastante que desear:

[TestMethod]
public void TestMethodThatShouldReturnAnException()
{
  try
  {
    CodeMachine machine = CodeMachineBuilder.Generate("KKKKK");
    Assert.Fail();
  }
  catch (IncorrectCharactersException){}
}

Un bloque catch vacío es una de las cosas menos recomendadas desarrollando software, ya que se pueden capturar excepciones que no deseamos. Por suerte, Microsoft ha puesto a nuestra disposición el siguiente artículo: A Unit Testing Walkthrough with Visual Studio Team Test, que, aunque algo antiguo, nos propone otra manera de controlar las excepciones en un test unitario:

[TestMethod]
[ExpectedException(typeof(IncorrectCharactersException))]
public void
TestMethodThatShouldReturnAnException
()
{
 CodeMachine machine = CodeMachineBuilder.Generate("KKKK");
}

Con un atributo llamado ExpectedException y el tipo de excepción que esperamos, podemos mantener el código limpio y elegante, así, podemos seguir con nuestras pruebas.

Mi primer Katayuno

Kata (Wikipedia): palabra japonesa que describe lo que en un inicio se consideró una serie, forma o secuencia de movimientos establecidos que se pueden practicar normalmente solo […].

Las artes marciales nos han enseñado que para ser buenos en algo, lo tenemos que repetir muchas, muchas veces. Este concepto se ha llevado a la programación, donde una kata es un pequeño ejercicio de código que plantea un problema que hemos de resolver de manera incremental, empleando TDD (desarrollo dirigido por tests), como si de la secuencia de movimientos de una kata se tratara.

El objetivo de estos ejercicios es mejorar nuestra capacidad de resolución de problemas y familiarizarnos con la manera de desarrollar a partir de pruebas. Estas katas se pueden hacer de manera individual, aunque si nos juntamos varios puede dar como resultado algo muy, muy interesante.

Esto es lo que ocurrió el pasado sábado en el grupo de AgileCyl, que organizaron lo que se conoce como Katayuno, reunir a un grupo de desarrolladores, programar por parejas una kata, y luego comentar la experiencia. En esta edición usamos Ruby, Python, Objective-C, Java, Javascript, C# y Groovy como lenguajes de programación, si no me dejo ninguno.

El funcionamiento fue el siguiente, hubo 3 iteraciones de 40 minutos con una pausa entre la segunda y la tercera para desayunar:

  • Primera iteración: Se desarrolla la kata por parejas, se introduce el concepto de TDD a aquellos que no estuvieran familiarizados.
  • Segunda iteración: Se cambian las parejas, se borra el código fuente (manteniendo el código de los test) y se re-escribe la kata. Es muy interesante porque el resultado puede llegar a ser bastante diferente a la primera iteración.
  • Tercera iteración: Se cambian las parejas (otra vez), se borra todo el código fuente y se re-escribe la kata en otro lenguaje de programación. Una vez más, es una tercera aproximación al mismo problema, aprovechando las características de cada lenguaje.

Al final de cada iteración tenìamos unos minutos en los que comentábamos qué nos había parecido la experiencia, sobre todo a aquellos que se enfrentaban, por primera vez, a un ejercicio de TDD.

La experiencia ha sido muy enriquecedora, he podido desarrollar con tres personas diferentes y tener tres puntos de vista del mismo problema, usando dos lenguajes de programación diferentes, he podido discutir sobre las ventajas o deventajas de usar según qué tipo de estructuras para problemas específicos. Espero poder repetir en el siguiente.