Test Driven Development, ¿por qué hacer las pruebas antes?

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:


Untitled-2


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 🙂

12 comentarios en “Test Driven Development, ¿por qué hacer las pruebas antes?”

  1. Hola Luis,

    Espero que no suelan recibir muchos feedbacks en forma de botella…. Jejeje

    Pero que conste que lo único que salió herido fue el ego de dos Avanades amantes del VB y de Enlib en la sala.

    En fin, me pongo de lado de Rodrigo porque pienso que ambas perspectivas son totalmente validas y como bien dices es mucho mas grande.

    Saludos.

    PD: Me lo pasé en grande y aprendimos un montón! Gracias.

  2. Hola Emlio, gracias 🙂

    Buenooo, si sacamos lo del EnLib 😛

    Por cierto, no quiro crear bandos eh, y menos si me toca estar en el contrario al de Rodrigo :D, en serio, la cosaes compartir las experiencias y en eso rodrigo también es grande, con lo que tiene muuucho que aportar 🙂

  3. Hombre… ya sabía yo que eras una persona inteligente 🙂 :-)… jaja en broma.. En este trabajo no hay partes no equipos distintos.. son puntos de vista. Desde luego esa sesión fué muy divertidad, aunque yo en este caso hiciera de follonero, y le dió un toque muy bueno a las sesiones, por un lado mostrar la posible charla plenaria y por otro tener cierto feedback.
    En cuanto a TDD efectivamente la refactorizacion te proporciona ventajas a la inversa, otra que podrías probar es ten el código de la prueba y despues haz Ctrl+R+M para sacar el método…

    P.D: Para nada me enfado todo lo contrario.. me divertí un huevo y tu creo que te divertistes el otro huevo 🙂

    P.D2: Me enfadaré como no cambieis las fotos :-), sobre todo la de los clavos encima del edificio y la de Copy Of Default.aspx(1) Copy Of Default.aspx(2) ….. Copy Of Default.aspx(n) JAJAJAJA

    Saludos
    Unai

  4. Yo no he estado ahí así que no se lo que se ha dicho o no, pero desde luego decir que en TDD las pruebas se pueden hacer después muestra una completa incomprensión de lo que es la esencia de TDD. Aquí no se trata de apoyar a una parte u otra, es entender los conceptos.

  5. Anonimo, puesto que no has estado ahí, pues bueno, no puedes opinar exactamente sobre lo que se ha dicho, de todos modos, ya digo que esto no se trata de redefinir TDD o no, si no de los puntos de vista basados en nuestra experiencia, con lo que agradecería que los comentarios fuesen constructivos.

    Reitero, no es sólo hablar sobre la «esencia» del TDD, si no de la necesidad de las pruebas y como hacerlas.

    Conviene recordar, además, uno de los principios del manifiesto ágil, «las personas por encima de las herramientas y los procesos», y aquí no especifica que unos procesos si se pueden adaptar en base a tu exeriencia y otros no, si bien, como dice Rodrigo,las pruebas unitarias NO son opcionales, son obligatorias, ahora bien, el procedimiento de hacerlas o incluso las herramientas, en base a nuestra experiencia, y te puedo asegurar que la de Rodrigo es mucha, se pueden hacer adaptaciones al proceso, siempre con mucho cuidado y con mucha experiencia, no es cambiar por cambiar.

  6. Perdona Luis, es cierto que no he estado ahí y lo afirmé, pero en base a esta frase de tu post:

    «la siempre puntillosa cuestión de hacer las pruebas unitarias antes o después del código haciendo TDD.»

    Ahí no hay lugar a duda. TDD => Pruebas antes. El resto me da igual. Yo no discuto si TDD es mejor o peor que hacer pruebas unitarias después, ni las ventajas que pueda o no pueda ofrecer, ni si se debe o no hacer pruebas unitarias, independientemente de si es TDD o no. Lo que digo es que decir que las pruebas unitarias se pueden hacer DESPUÉS siguiendo una metodología TDD es un ERROR.

    Perdona si crees que no tengo derecho a «opinar» sobre lo que ha dicho. Es tu blog y tienes pleno derecho a prohibir o ignorar a la gente.

  7. Por supuesto que tienes derecho a opinar, y estoy de acuerdo contigo en que TDD es probar antes.

    Pero lo que busco es que no se quede en que decir una cosa u otra, si no en compartir experiencias.

  8. Pues perdona que sea pesado, pero dado el contexto del post, dado la frase que mencionas y dado que el título también pone «Test Driven Development, pruebas antes o después», creo que teniendo un blog público ,es MUY importante no confundir a las personas que no tienen las ideas claras y enviarles mensajes equivocados.

    Si realmente se trata de ver los beneficios de TDD, pues ponlo en contexto.

    Yo no pierdo mi tiempo ni hago comentarios para dar por culo. Lo hago porque creo que el post puede dar lugar a malentendidos por parte de personas que no tienen experiencias en TDD o no saben de que va. A mi realmente me da igual si hay gente que piense que en TDD se puede hacer las pruebas antes, peor para ellos. Pero cuando una persona, como tú, que es un MVP y representa una serie de valores/conocimientos escribe un post, debe hacerlo con responsabilidad porque muchos inexpertos pueden basar su forma de trabajo en lo que tu, yo u otro pueda escribir.

    ¿Críticas constructivas? Soy el primero en dar críticas constructivas, pero cuando hay un error, hay que decirlo también.

    Pero vamos, creo que he dado mi punto de vista y no tengo mucho más que añadir. Gracias por dejarme compartir en tu blog.

  9. Nadie dice que estés molestando.

    Y tu opinión es bienvenida por mi parte, y ciertamente tienes razón en muchas cosas de las que dices, por lo que cambio el título.

  10. mmm … yo el otro día me reservé la opinión ya que TDD se desprende de una teoría y una base super atractiva, pero después (como todo) es necesario madurarla y adaptarla a cada negocio.

    Sin embargo, no puedo dejar de postear este estudio sobre 2 grupos de estudiantes trabajando side-by-side, un equipo basado en Test-First y otro con Test-Last. Especial atención a las conclusiones del estudio (que en realidad era sobre desarrollo guíado por tests)

    http://scruffylookingcatherder.com/archive/2008/01/22/tdd-proven-effective-or-is-it.aspx

    Saludos

  11. Buenas,

    Antes de meterme en materia: me parece un debate súper enriquecedor. ¡Lástima no haber estado presente!

    Respecto a la pequeña polémica en cuanto al título del post, estoy de acuerdo con Anónimo: TDD = Test-first. En ese sentido, no deberíamos inducir a equívocos en nuestros lectores. Aunque, si bien, un blog es la opinión personal de quien lo escribe y no tiene porqué ajustarse con definiciones «académicas» (para eso está la Wikipedia, por ejemplo) sí que es cierto que en cuanto a nomenclaturas y principios básicos debe no introducir ambigüedad.

    Dicho todo esto, voy a entrar realmente a posicionarme en el debate; aunque os avanzo que mi respuesta no va a ser categórica y podría posicionarme tanto en un lado como en otro pero en ambos casos mi respuesta iría acompañada de la coletilla «pero…».

    Por resumir, me estoy dispersando cual developer que no utiliza test-first, mi opinión es similar a la de Bruno. Fijaros en el artículo que aporta sobre la comparativa entre test-first y test-last. Me quedo con el siguiente fragmento:

    «Truly problematic, however, are the quality results. That’s simply a disaster if you propound «Test First» as a guarantor of quality. I mean, sure, the number of unit tests per functional unit suggests a minimum quality through increased testing, but that’s only interesting in a situation where minimum quality is important (like, for example, at NASA or in code embedded in medical equipment). The lack of any other correlation here is pretty pronounced any way you care to slice the data. Having a big clump in that upper left quadrant is troubling enough but then having the «Test Last» group almost double your «Test First» group in the over 90% quality range is something that should be noticed and highlighted.»

    Y por terminar de liar el tema, la respuesta que yo daría es:

    «Pruebas antes Y pruebas después. A mi modo de ver, la técnica Test-First (TDD) es un catalizador para el desarrollo del código pero no una garantía suficiente de calidad (véase párrafo del artículo donde se habla de «calidad mínima»)»

    Nos vemos en el Lanzamiento!

Responder a anonymous Cancelar respuesta

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