Ayuda me urge (ejemplo ε TDD)

Espero que los pasos sean sólo para ilustrar y que no lo hayas programado exactamente así porque es lo más tardado del mundo...

Algo tan sencillo lo puedes programar completo desde el inicio (me refiero al validador). Y las pruebas puedes escribirlas también todas juntas, pero cada una por separado:

Si haces eso desde el principio, ya sabes todas las condiciones que tienes que validar. Y al principio saldrán un montón de rojo pero pues tu meta es llegar a puras verdes. Y la validación, pues es cuestión personal, a mi me gusta más esto porque primero validas la cadena y luego creas solamente un File:

@ezamudio Tiene que ver con la experiencia y las veces que has hecho esto anteriormente, como tu ya sabes de que se trata puedes hacerlo así, pero lo que estás haciendo es agregar pruebas a tu desarrollo y no un desarrollo dirigido por pruebas. Son dos cosas diferentes.

El TDD hace énfasis en exagerar en lo que parece obvio y en solamente poner el código más simple que haga funcionar la prueba, aún si esto implica hacer una prueba que solamente regrese  . Podrá parecer tardado, pero en realidad ¿que tan tardado es escribir y correr un test de algo que regresa true? alrededor de 10 - 20 segundos, que ciertamente en acumulado en el año tendrá un impacto pero obviarlo sería una microoptimización y/o en última instancia otro tipo de desarrollo.

Hacer ese cambio de switch es lo más difícil al adoptar TDD muchas de las pruebas parecen ridículas, pero también son sumamente fáciles de hacer. La idea detrás de esto es que esas pruebas sean las que dicten el diseño del software y no que un diseño pre-concebido sea al que se le agreguen pruebas.

Que es una posición extrema? Pues si. Que hay muchos detractores del TDD? también, que hay que ser pragmático al usar TDD, también.

Es interesante el tema.

@ezamudio incluso me faltaron las iteraciones del refactoring.
 
También me gusta separar las pruebas, pero solo en casos cuando tengo algo como (tal vez muy exagerado):
 

Y cuando las dejo todas juntas como en el ejemplo, siempre les pongo una descripción a los pruebas, porque me pasaba que tenía unas ~30 y me perdía al buscar cuál de todas trono.
(offTopic) Odio eclipse pero es el que uso en el trabajo y algo que se me hace muy importante es usar los atajos del teclado para hacer las pruebas de una manera natural.
Ya por último, las cosas que más se me dificultan son: No escribir código de más y escribir las pruebas correctas en el momento correcto.
Gracias por los consejos.

Buen post.

Todavia me falla lo del Refactoring, estoy checando teoría y ejemplos.

Programar con TDD es bastante tardado (es verdad), cuesta mucho trabajo. Sin embargo es bueno aprender cosas nuevas ... no?

?:)

@Mr(-) Lee este post a ver si te hace sentido el refactoring.

Lo difícil del refactoring ( al igual que del TDD ) es cambiar el switch mental al hacerlo.

Con el TDD se escribe primero la prueba y eso guía el diseño de la solución, hay que hacer un switch mental ahí.

Con el refactoring el switch mental que hay que cambiar es que cuando se hace refactoring NO se están corrigiendo bugs, ni agregando funcionalidad. Lo cual es al principio muy extraño porque se puede pensa "¿entonces para que lo hago?" la respuesta es, para mejorar el diseño del código.

Como no se quitan bugs ni se agrega funcionalidad, el refactoring pudiera parecer ocioso, pero no lo es. El valor que da es que permiten que los nuevos cambios puedan agregarse más fácilmente.

Buen post!