10 razones para evitar el Desarrollo Dirigido por Tests

Como saben los que me siguen habitualmente, de vez en cuando me da por traducir algún artículo, con la intención de acercar información interesante a los más perezosos a la hora de leer en inglés. Éste es otro de esos artículos.

En este caso he traducido el artículo 10 Reasons to Avoid Test Driven Development, de Assaf Stone. No sé la licencia que tiene… no pone nada en su web.

Espero que os guste tanto como a mí.

10 razones para evitar TDD

El Desarrollo Dirigido por Tests (TDD), y todas sus variantes (BDD, ATDD) son en mi opinión buenos métodos para dirigir los esfuerzos de desarrollo de cualquier grupo, e incrementar la calidad el producto. Pero TDD no es una bala de plata. No encaja en todos los proyectos. El siguiente artículo lista las 10 principales razones para no escribir tests automatizados para tu código.

Si se te aplica una o más de estas condiciones, deberías considerar olvidar TDD y, de hecho, todas las demás técnicas ágiles, ya que serán un esfuerzo desperdiciado:

10. No hay cliente

A veces se desarrolla un producto que nunca usará nadie. En este caso, cualquier esfuerzo dedicado por mejorar la calidad es un completo desperdicio. A nadie le importará.

9. El cliente es un téster ávido

Hay gente que adora más que nada probar software inestable (beta). La diversión de encontrar nuevos errores y tratar de imaginar qué fue mal es su razón de vivir. Otros son científicos de corazón, y adoran mirar trazas de error, para hacer ingeniería inversa en el código. Si da la casualidad de que tu cliente es uno de esos, entonces escribir tests automatizados le quitará toda la diversión a tu código. ¡No lo hagas!

8. El proyecto es corto, simple y directo

Si tu equipo puede completar el proyecto en un periodo de tiempo corto (no más de unas semanas), y nunca, jamás tendrá que volver a abrirlo por mantenimiento, entonces los beneficios de la mantenibilidad, reusabilidad y extensibilidad se perderán. Dedicar tiempo y esfuerzo a estos valores es desperdiciarlo.

7. Tu arquitectura es perfecta

Si no hay forma de mejorar tu arquitectura, entonces no hay necesidad de que sea extensible. TDD, por su flujo de desarrollo incremental, fuerza a la arquitectura a ser extensible, simplemente haciéndote extenderla a medida que avanzas, y esto, como pintalabios en un cerdo, es algo que simplemente no necesitas.

6. Tu documentación es perfecta

Nunca olvidas una API, y cualquier cambio que hagas en tu software se documenta instantáneamente. Los tests que creas con TDD sirven como documentación, un ejemplo de cómo utilizar la API. Los tests correctamente nombrados y escritos explican el contexto del test, por lo que resulta sencillo encontrar el test que te muestra lo que necesitas entender. Tu documentación es tan completa, que escribir tests es una clara violación del principio DRY, así que claramente deberías evitar las pruebas.

5. Tu equipo nunca cambia y todas las memorias de sus miembros son perfectas

La memoria colectiva nunca olvida cada una de las líneas de código que escribió, o cuál era el contexto cuando la escribió. En ese caso, no necesitas las pruebas para recordarte lo que hace el código, por qué lo hace o cuál es la causa de ello. También significa que los miembros de tu equipo nunca se marchan, o se reclutan nuevos miembros, porque si este ocurriese, perderías información, o habría miembros que no recuerdan el código (sin haber estado allí cuando se escribió). Si este es el caso, no te molestes con las pruebas; tan solo interferirán en tu increible velocidad.

4. “Hecho” significa que el código está terminado

Muchos equipos tienen una definición de hecho (DoD) que significa que la característica está “hecha” cuando se encuentra en un estado tal que el usuario final puede recibir y ejecutar (codificada, probada, desplegada, documentada, etc.). Muchos otros en cambio, tu equipo incluido, prefieren una definición más sencilla y fácil de obtener que acepta “terminado” como “hecho”. Para ti es suficienet con que el desarrollador declare que él o ella completó su parte, y cualquier otra cosa es responsabilidad de otro. Si no necesitas que el código se pruebe por el dueño del producto / director / usuario para aceptarlo, entonces lo mejor que puedes hacer es pasar a la siguiente característica ya mismo, en lugar de alargar tu relación con esta característica.

3. Te pagan por codificar, no por probar

Ignorando el hecho de que los tests son código (sorpresa), las pruebas están hechas para probar. Quizá tu equipo de testers es suficientemente rápido como para ejecutar las pruebas a medida que tú codificas, y darte feedback en pocos segundos, señalando las zonas en las que rompiste el código, de manera que puedas arreglarlo mientras los cambios están frescos en tu mente, así como una suite de regresión completa del producto, en caso de que hayas roto algo en un componente distinto cada noche (a ellos no les importa trabajar por las noches; adoran el silencio absoluto). Bien por ti, cuida esos testers, y asegúrate de que tienen suficiente trabajo como para no aburrirse e irse a otra compañía que les ofrezca mejores retos.

2. Depurar no cuenta, y probar requiere mucho tiempo

Como en cualquier empresa competitiva, tu equipo debe entregar a tiempo, lo que significa que deben estimar cuándo se entregará. Ya que tu DoD no incluye pruebas, y probablemente no podrás adivinar cuánto tiempo te llevará depurar la característica, lo que implica todo el ciclo de tira y afloja entre desarrollo y QA, sólo tienes que estimar cuánto tiempo te llevará codificarlo. Si quieres cumplir la fecha, no es necesario que añadas el 20% de margen en tu tiempo de entrega o perderás la fecha final. Peor aún, si añades el 20% a tus estimaciones, tu jefe podría pensar que estás rellenando las estimaciones, lo que es su trabajo. Si ocurre esto, ¿quién sabe lo que podría pasar? Es mejor jugar sobre seguro.

1. Sólo es una teoría

Como la Evolución (y la Gravedad), sólo es una teoría. Incluso si todas las razones de más arriba no fueran válidas, nunca nadie ha probado de forma inequívoca que este producto podría haberse hecho más rápido y con mejor calidad usando las metodologías de desarrollo new-age como TDD. Es solo una cuestión de opinión.

Prueba tú mismo

Ahora, para probar si deberías usar el desarrollo dirigido por pruebas o no, vuelve a la lista. Cuenta cuántas razones te puedes aplicar. Si tienes diez puntos, no uses TDD. De hecho, si marcaste más de uno (la razón #8 podría hasta ser legítima), no escribas nada de código. Quizás serías más útil eligiendo una carrera que tenga menos incógnitas y partes móviles. ¿Quizá pavimentar carreteras?

Artículo original: Assaf Stone Traducción: Miguel Ángel García