Hace tiempo que llevo pendiente compensar el desequilibrio en artículos técnicos que últimamente tengo en el blog, así que aquí va éste.
El pasado día 22 de diciembre celebramos el segundo aniversario del primer coding dojo que organizamos como AGILISMO.es. Luis Rivera, siempre disponible para echarnos una mano, nos prestó las instalaciones de Okuri, también conocidas como Tetuan Valley porque allí tiene la sede esta iniciativa de incubación y aceleración de startups en Madrid. Echamos de menos a Alejandro y Roberto, de Autentia, a los que tanto tenemos que agradecer durante estos dos años. Pero junto a los habituales también estuvo gente nueva. Eso es buena señal.
Hasta aquí no parece un artículo técnico, ¿verdad? Bueno, pues al grano. Durante el desarrollo del coding dojo, con la PomodoroKata como ejercicio, surgió un debate sobre si dejar el número 25 en los primeros pasos del desarrollo es aceptable o no. Xavi defendía la sustitución del 25 por una constante por tratarse de un número mágico mientras que @mikelodeon opinaba que era suficientemente expresivo y que el refactor era prematuro.
Como podeis comprobar en el video de la kata que grabé hace ya dos años, yo también prefiero sustituir el 25 por una constante (minuto 1:40 aprox) por las siguientes razones:
* el método minutesLeft devolviendo 25 es menos expresivo que minutesLeft devolviendo DEFAULT_DURATION
* en el test también hago este refactor aunque el título del test es incorrecto y debería decir "Un pomodoro tiene una duración por defecto", porque realmente me es indiferente cuál sea esa duración
* si realmente hubiera querido probar que la duración por defecto es 25 entonces debería haber tenido un test del tipo: assertEquals("La duración por defecto es 25", 25, Pomodoro.DEFAULT_DURATION), lo que nos habría llevado a pasar esa constante de privada a pública.
Como veis, mis argumentos están basados en la expresividad del código y en que se ajusten a lo que se quiere probar. El trabajo más difícil es siempre elegir bien los tests porque, dependiendo de ellos, nuestro diseño y posterior implementación tomarán un rumbo u otro.