TDD y Yo

Hace poco comencé un nuevo desarrollo y decidí grabar algunos videos de los cuales solo publiqué los primeros tres. Sucede que el hecho de saber que alguien me estaba mirando me hacía prestar mayor atención a mis palabras que al código que debía escribir. No obstante a ello, continué grabándome para tomar el tiempo y estudiarme.

La primera parte de ese desarrollo está completado y estos son los números:

66 pruebas unitarias.
15 clases. (solo 4 centrales, el resto son datacontracts, excepciones y helpers)
238 líneas de código.
300 líneas de pruebas.
1,2605 líneas de pruebas por cada líneas de código del producto.
73 es el menor índice de mantenibilidad que obtuve. 88,9 es la media.
97,74% de cobertura total.
26 horas de programación.

9,15 LOC/hora
11 LOC(test)/hora.

Como nunca me medí mi productividad ni conozco la densidad de defectos que tiene este código ni ningún otro que haya escrito, no puedo hacer comparaciones pero sí puedo sacar algunas conclusiones y dar mis apreciaciones personales.

  • TDD te lleva a realizar muchas pruebas. Si eres riguroso y no aceptas introducir ninguna línea de código sin antes tener una prueba que la respalde, terminas escribiendo muchas pruebas.
  • Muy alta cobertura de código, el único código sin pruebas es aquel que ha surgido de las recomendaciones del analizador estático de código con respecto al número de constructores que requieren las excepciones. (No obstante, nada impide que cree pruebas para estos)
  • Más líneas de pruebas que líneas de producto. Esto lo he visto antes pero para el mix “mal código-malas pruebas” pero parece que puede darse en este caso también. Debo aclarar aquí que así como el código se fue refactorizando minuto a minuto, las pruebas también fueron refactorizadas al punto tal que no existe en el proyecto ninguna prueba de más de 9 LOCs. Incluso puede verse en las capturas que existe una jerarquía de clases para las pruebas.
  • Aún el menor índice de mantenibilidad es elevadísimo. Si no me crees, obtén las métricas de tu proyecto actual.
  • Realmente no sé si 9.15 LOC/hs es algo bueno o no. A mi entender, es un número excelente ya que , haciendo un cálculo infantil (lineal), representarían casi 1.500 LOCs/mes. Ahora que si contemplamos las pruebas como algo de valor y las agregamos daría 3224 LOCs/mes, lo que a mi parecer es sumamente bueno.

 

image 

image

image

image

Sin categoría

One thought on “TDD y Yo

  1. Hola. Pues habría que ver que porción de la funcionalidad total de la aplicación conforman esas 238 líneas de código, pero, a priori, te digo que desde el punto de vista productivo me parecen una aberración las cifras que manejas.

    Quiero decir que para una cantidad tan ínfima de código me resulta a todas luces desproporcionada tal cantidad de pruebas unitarias. Yo, por mi parte, soy más partidario de minimizar esta práctica (atendiendo a las áreas críticas o más susceptibles de fallo en el desarrollo) y potenciar de forma notable otras como la integración y pruebas continuas, la figura del beta-tester y, por encima de todo, el sentido común. Todo lo demás me parece burocracia innecesaria.

    Salu2!

Responder a anonymous Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *