Fuera del contexto ágil, ATDD tiene pocas probabilidades de éxito ya que si los analistas no trabajan estrechamente con los desarrolladores y testers, no se podrá originar un flujo de comunicación suficientemente rico como para que las preguntas y respuestas aporten valor al negocio.
Si en lugar de ejemplos, se siguen escribiendo descripciones, estaremos aumentando la cantidad de trabajo considerablemente con lo cual el aumento de coste puede no retornar la inversión. Si los dueños de producto (cliente y analistas) no tienen tiempo para definir los tests de aceptación, no tiene sentido encargárselos a los desarrolladores, sería malgastar el dinero. Tener tiempo es un asunto muy relativo y muy delicado.
No entraremos en ese tema tan escabroso al que yo llamaría más bien estar dispuestos a invertir el tiempo, más que tener o no tener tiempo. ¿Alguien tiene tiempo?. La herramienta con la que se escriben los tests de aceptación tiene que minimizar la cantidad de código que requiere esa conexión entre las frases y el código del sistema, si no, el mantenimiento se encarecerá demasiado.
ATDD/STDD es un engranaje que cuesta poner en marcha pero que da sus frutos, como se puede leer en este artículo de la revista Better Software de 2004.
Desgraciadamente no podemos extendernos más con respecto a ATDD/STDD, si bien se podría escribir un libro sobre ello. Mike Cohn escribió uno muy popular titulado User Stories Applied que le recomiendo encarecidamente leer. Mención especial también al capítulo sobre ATDD de Lasse Koskela en Test Driven y los sucesivos, que incluyen ejemplos sobre el framework FIT.
Gojko Adzic tiene un libro basado en FitNesse y por supuesto cabe destacar su famoso libro sobre Acceptance Testing. Elisabeth Hendrickson, en colaboración con otros expertos de la talla de Brian Marick, publicó un paper que puede leerse online e incluye ejemplos en el framework Robot.
En la parte práctica de este libro tendremos ocasión de ver algunos ejemplos más aunque, por motivos de espacio, no es exhaustiva.