Lo primero, bueno, hace mucho que no escribía, y sí, se que eso es un error a la hora de mantener un blog, pero lo cierto es que entre unas cosas y otras, andaba liado, y sin muchas ganas de escribir, pero bueno, cojo el toro por los cuernos y vuelvo a la carga.

Ayer, con mis amigos Rodrigo Corral, Bruno Capuano, y Unai Zorrilla (O Bruxo Mobile El follonero), surgió una interesante cuestión acerca del TDD, y es, la siempre puntillosa cuestión de hacer las pruebas unitarias antes siguiendo TDD al pie de a letra o después del código, que se saldría en parte de la definición de TDD.

La propia definición específica de TDD, dice que las pruebas se han de escribir siempre antes que el código, cosa que a veces es difícil de hacer entender y explicar a gente “novel” en el tema del TDD.

Si bien es cierto que en algunos sitios si que he visto gente que dice que a pesar de hacer TDD, hacen las pruebas después, y además Rodrigo ayer, nos comentó que el tenía una referencia de uno de los “grandes” que da dos aproximaciones “Test at first” (test al principio) y “Test at last” (test al final).

Tampoco escribo este post para que el follonero Unai, rodrigo, Bruno, et al. nos metamos de nuevo en una discusión jeje, sólo pretendo exponer mis ventajas, y si digo “mis”, ya que estoy hablando desde mi punto de vista subjetivo (como veis hablaré siempre en primera persona), de como me ayuda el tema de hacer la prueba al principio:

1. Las pruebas me dan la funcionalidad, si, si empiezo diseñando la prueba, se me hace más claro que tiene que hacer exactamente el método, con lo cual, me disperso menos a la hora de la realización del método, y por tanto, menos dispersión == menos fallos.
2. Diseño, al hilo con lo anterior, la prueba me da el diseño del método, que necesito de entrada, que voy a obtener de salida, y que tiene que pasar entre medias, esto es muy parecido a la anterior, si, pero aquí ya bajo de nivel a la parte más puramente técnica.
3. K.I.S.S., keep it simple stupid, yo soy de los que siempre empiezan a pensar “¿y si añado este if aquí y este for aquí?”, con esto consigo que el código que haga, sea totalmente dirigido a solucionar la prueba, ni más ni menos, para futuras situaciones, casuísticas, tendré más pruebas.
4. Cobertura de código, esto es básico, si hago todo los puntos anteriores, consigo una mayor cobertura de código.

Bueno, esta es mi pequeña aportación a porque lo hago así, además, con Visual Studio 2008 (¡¡¡¡venid al lanzamiento!!!!) todos sabemos que tenemos la posibilidad de crear el método y luego darle al botón de crear pruebas unitarias, lo cual es muy tentador, pero yo os hago la propuesta inversa, cread la prueba, y hacer la llamada al método fantasma con los parámetros (tanto de entrada como de salida) necesarios, y luego, una vez terminada de escribir la prueba, ejecutarla y recibir el puntito rojo, sobre esa línea de código de la llamada al método fantasma pulsad (con los settings de VS C#) Alt+Shift+F10, y milagro, os sale esto:

Vaya, con esto, podemos generar la definición del método en la clase adecuada, y favoreciendo el TDD.

Por supuesto, y aunque yo me declare a favor de hacer la prueba siempre antes, es una opinión basada en mi propia experiencia, y aquí está el punto clave, nuestra experiencia, pero como siempre, aconsejo que empezemos (siempre que no tengamos experiencia previa) basándonos en el conocimiento de los que nos han precedido, y en este caso yo apostaría por el mantra del TDD: red, green, refactor.

PD: Unai, jeje no me odies por lo de el follonero, y de veras, fue muy divertido, y gracias por el feedback 🙂

PDII: Vale Rodrigo, me he puesto de parte de Unai, pero no me pegues muy fuerte, que eres mucho más grande que yo 🙂