#11 Antes de sentarse a programar hay que escribir, eso es lo único que digo, ni flujo de ejecución ni nada, las ideas al papel.

#13 El papel es tan de los 2000... Ahora, antes de escribir código, deberías empezar por tus tests. Así no se te olvida lo que estás haciendo:

- Test, que falle
- Lo arreglas, commit
- Otro test, que falle
- Lo arreglas, commit

Así, te interrumpan cuando te interrumpan, puedes seguir donde estabas, ya que un test incluye bastante de lo que pensabas hacer en el código y a veces cómo pensabas abordarlo.

Típico test que está sin solucionar:

```js
var popup = popupModule.createPopup('#popup', '#trigger');
$('#trigger').trigger('click');
expect($('#popup').is(':visible').toBeTruthy()
```

Cuando me encuentro ese test que falla, sé perfectamente qué es lo que tengo que implementar.

#14 #15 #20 #25 #27 El TDD sólo sirve cuando la idea ya está avanzada. Si lo que estás haciendo es diseñar un componente desde cero, desde la idea abstracta, es absolutamente inútil.

TDD está bien para los desarrolladores puros, a los que se les dan las estructuras ya pensadas y lo "único" que tienen que hacer es programar (nótense las comillas en "único", no estoy despreciando esta tarea en absoluto). No han sido pocas las veces que he visto usar TDD para sistemas completamente nuevos y al final acabas programando dos veces: primero los tests, luego la implementación inicial, luego rehaces los tests porque te has dado cuenta de que necesitabas otras APIs diferentes y luego, finalmente, la implementación que encaje con los nuevos tests.

#29 que es un desarrollador puro??? creo que en cualquier proyecto en el que trabajes todo el mundo es desarrollador.
TDD funciona muy bien para fases iniciales, pero hay que saber escribir tests y saber lo que se quiere conseguir y eso no todo el mundo sabe hacerlo

#29 El TDD sirve todo el rato,... TDD no significa que los tests no se puedan cambiar más adelante, borrar, o combinar... La idea del TDD es que no es sólo útil para que tu aplicación esté probada, sino para ayudarte a establecer un ciclo de trabajo y a pensar, antes de picar código, qué demonios es lo que quieres hacer.

Lo que es una tontería es ser super estricto y estar haciendo tests para cada pequeña porción de lógica que añades, pero pensar "outside-in" en lugar de "inside-out" es muy útil a la hora de hacer código que sea cómodo de usar.

Cuántas veces, antes de empezar a programar una clase, hemos hecho un pequeño boceto en código de cómo usaríamos esa clase... Pues bien, una vez esta uno acostumbrado a escribir tests, ese código que uno luego tiraría a la basura, lo hace en formato test, y esto ayuda muchísimo a ir hilando ideas...

Y como dice #30 no todo el mundo sabe hacer tests, y para mucha gente esto es poco productivo. Pero a mi me funciona para el 50-60% de código que hago... El truco es tener 10-15 estrategias distintas a la hora de afrontar algo, de plantearse cómo testearlo. No todo tiene que tener 20 mocks y 200 tests. Y no hay que ser talibán ni de TDD ni de lo contrario (no tener ni un santo test). A veces, con escribir 4 o 5 tests inicialmente para un código en el que trabajarás 4 horas es una aproximación muy válida. No siempre hay que tener esos mini-ciclos de un test, al menos es mi opinión, que eso no funciona para todo tipo de códigos.

Por ejemplo, el otro día programando el código de pathfinding de un juego, pues hacer TDD me ayudó a establecer qué formato iba a dar a los nodos y segmentos, y qué cosas iba a esperar... Fue entonces cuando me fui dando cuenta de cuándo quería ids de nodos, y cuándo píxeles... Si no hubiera hecho los tests primero, me habría dado cuenta a medias y tendría que haberlo cambiado todo 3 ó 4 veces.

#30 (y #32 y #34) Desde mi punto de vista, un desarrollador puro es alguien a quien le dan las interfaces/objetos/esquemas ya hechos y "sólo" tiene que modelarlo en la tecnología escogida.

No todo el mundo programa ni todo desarrollador hace sólo programación. De ahí lo de "puro". Alguien que sólo desarrolle, o sea, que sólo programe.

Te pongo un ejemplo que he tenido hace poco: estábamos tratando con crowdsourcing y necesitábamos un componente que pudiera verificar cómo de fiables eran los diferentes datos que se estaban subiendo. Todavía es una idea abstracta, no puedes definir ni tests ni interfaces ni nada. Ni siquiera tienes claro qué tipos de entradas y salidas vas a necesitar.

Durante las primeras horas (o días o incluso semanas), lo único que vas a hacer es leer fuentes, pensar, hacer algún esquema no muy concreto y hablar con gente que creas que puede aportarte ideas.

Ahí ni el TDD ni ninguna técnica de programación podrá ayudarte. Estás sólo tú con tus ideas felices.

TDD sólo sirve cuando la idea ya está avanzada, esquematizada y repensada. Que yo no sé vosotros, pero en mi trabajo eso suele ser menos de la mitad del tiempo.

#33 TDD sólo sirve cuando sabes lo que quieres hacer, como cualquier otra técnica de programación del mundo. De todos modos en ocasiones una aproximación con BDD y tratando de definir ejemplos de lo que quieres ayuda bastante, y si lo haces bien esos mismos ejemplos posteriormente se convierten en las pruebas de aceptación de tu sistema. Luego, la idea del "programador" como alguien que codifica en base a un diseño entregado por otro, vamos el waterfall de toda la vida, hace siglos que esta desterrada de cualquier equipo de programación medianamente competente, the design is the code decía jack reeves hace muchos, muchos años (dale al google y leete los artículos).

#32 En problemas puramente algoritmicos TDD no ayuda al diseño de algoritmos, para eso existen tecncias de algoritmia, en estos casos puede ser suficiente con tener algunos test iniciales y usarlos simplemente como método de comprobación para saber cuando hemos terminado, pero no como técnica de diseño del propio algoritmo, esto quedo bastante claro con el famoso asunto del sudoku y Ron Jeffries (uno de los integrantes del equipo original del proyecto C3 con Kent Beck donde se empezo a utilizar esto del TDD). Para el resto de problemas la aproximación en baby steps suele dar buenos resultados, tu código crece de manera mucho más sana, sobre todo si haces buen uso de la fase de refactor.

#29 Hombre, si te pones a picar código a lo loco, sin pensar un poco antes lo que quieres hacer y cómo estructurarlo, pues claro que no funciona. Pero es que tampoco te va a funcionar de otra manera, el código va a ser una locura hasta que se estabilice.

Llevamos 50 años de ingeniería del software por algo. Lo de ponerse a picar sobre la marcha puede servir para un script de tres al cuarto, pero para poco más.

#14 cuando tienes que diseñar algo con cierta estructura el TDD (en el sentido estricto red->green->refactor) no ayuda. Lo que ayuda es el papel y boli.

#25 Tienes razón que en el sentido estricto no funciona del todo bien a la hora de diseñar algo. Pero por ejemplo, siempre se dice que diseñar un API es la mejor forma de diseñar un sistema, ya que ayuda a la hora de buscar qué tipo de uso se le va a dar al sistema.

Pues bien, si en lugar de usar papel y boli, se hace una base de datos y se programa un cliente del api en forma de unit tests (o tests de comportamiento), ese cliente (que se podrá ir cambiando, claro) es una documentación, una hoja de ruta perfecta. Y es cierto que en ese caso, lo ideal es ir en grupos de tests, no de uno en uno.

#7 En antena3 duraría un mes con las repiticiones

#11 En A3 en vez de 12 días llevaría 12 años. Cosas de la publicidad.

#25 #32 El de Heisenberg parece de una marca de cerveza