¿Cuáles son algunas de las razones por las que un único desarrollador debería utilizar TDD?[cerrado]

https://stackoverflow.com/questions/157717

03-07-2019
|

Pregunta

Soy un programador contratado con mucha experiencia.Estoy acostumbrado a que un cliente me contrate para realizar un proyecto de software de una forma u otra por mi cuenta, generalmente de la nada.Eso significa borrón y cuenta nueva, casi siempre.Puedo incorporar bibliotecas que he desarrollado para comenzar rápidamente, pero siempre son opcionales.(y depender de obtener las cláusulas de propiedad intelectual correctas en el contrato) Muchas veces puedo especificar o incluso diseñar el hardware plataforma...entonces estamos hablando de libertad seria aquí.

Puedo ver usos para construir pruebas automatizadas para cierto código:Bibliotecas con funcionalidades más que triviales, funcionalidades centrales con un gran número de referencias, etc.Básicamente, a medida que el valor de un fragmento de código aumenta debido al uso intensivo, puedo ver que sería cada vez más valioso probar ese código automáticamente para saber que no lo romperé.

Sin embargo, en mi situación, Me resulta difícil racionalizar algo más que eso.Adoptaré las cosas a medida que resulten útiles, pero no voy a seguir nada ciegamente.

Encuentro que muchas de las cosas que hago en "mantenimiento" son en realidad pequeños cambios de diseño.En este caso las pruebas no me habrían ahorrado nada y ahora tendrían que cambiar también.Un enfoque de diseño altamente iterativo y basado en el primer trozo funciona muy bien para mí.No creo que pueda ahorrarme tanto tiempo con pruebas más exhaustivas.

Los proyectos de hobby son aún más difíciles de justificar...Por lo general, son desde fines de semana hasta, digamos, un mes de duración.Los errores en los casos extremos rara vez importan, se trata de jugar con algo.

Lectura de preguntas como Éste, La respuesta más votada parece decir que, según la experiencia/opinión de ese cartel, TDD en realidad es una pérdida de tiempo si tienes menos de 5 personas (incluso asumiendo un cierto nivel de competencia/experiencia con TDD).Sin embargo, eso parece cubrir el tiempo de desarrollo inicial, no el mantenimiento.No está claro cómo se acumula TDD a lo largo de todo el ciclo de vida de un proyecto.

Creo que TDD podría ser un buen paso hacia el valioso objetivo de mejorar la calidad de los productos de nuestra industria en su conjunto.Sin embargo, el idealismo por sí solo ya no es tan eficaz para motivarme.

I hacer Creo que TDD sería un buen enfoque en equipos grandes o en equipos de cualquier tamaño que contengan al menos un programador no confiable.Esa no es mi pregunta.

¿Por qué un único desarrollador con un buen historial adoptaría TDD?

Me encantaría conocer cualquier tipo de métrica realizada (formalmente o no) en TDD...centrándose en desarrolladores individuales o equipos muy pequeños.

En su defecto, también estaría bien contar anécdotas de sus experiencias personales.:)

Por favor evite expresar opiniones sin experiencia que las respalde.No hagamos de esto una guerra de ideologías.También el argumento de omitir mayores opciones de empleo. Ésta es simplemente una cuestión de eficiencia.

Solución

No estoy dispuesto a seguir nada a ciegas.

Esa es la actitud correcta. Uso TDD todo el tiempo, pero no me adhiero a él tan estrictamente como algunos.

El mejor argumento (en mi opinión) a favor de TDD es que obtienes un conjunto de pruebas que puedes ejecutar cuando finalmente llegas a las fases de refactorización y mantenimiento de tu proyecto. Si esta es su única razón para usar TDD, puede escribir las pruebas en cualquier momento que desee, en lugar de seguir ciegamente la metodología.

La otra razón por la que uso TDD es que escribir pruebas me hace pensar en mi API por adelantado. Me veo obligado a pensar en cómo voy a usar una clase antes de escribirla. Conseguir mi cabeza en el proyecto a este alto nivel me funciona. Hay otras formas de hacer esto, y si ha encontrado otros métodos (hay muchos) para hacer lo mismo, entonces diría que siga haciendo lo que funcione para usted.

Otros consejos

Lo encuentro aún más útil cuando vuelo solo. Con nadie cerca para intercambiar ideas y nadie para realizar revisiones por pares, necesitará cierta seguridad de que su código es sólido. TDD / BDD le brindará esa garantía. Sin embargo, TDD es un poco contradictorio. Otros pueden estar completamente en desacuerdo con lo que estoy diciendo.

EDITAR: ¿Puedo agregar que si se hace correctamente, en realidad puede generar especificaciones para su software al mismo tiempo que escribe las pruebas. Este es un gran efecto secundario de BDD. Puedes hacerte parecer un súper desarrollador si estás elaborando código sólido junto con especificaciones, todo por tu cuenta.

Ok, mi turno ... haría TDD incluso por mi cuenta (para código no espiga / experimental / prototipo) porque

Piensa antes de saltar : me obliga a pensar en lo que quiero hacer antes de comenzar a extraer el código. ¿Qué estoy tratando de lograr aquí? 'Si supongo que ya tenía esta pieza ... ¿cómo esperaría que funcione?' Fomenta el diseño de objetos en la interfaz.
Más fácil de cambiar : puedo hacer modificaciones con confianza ... "No rompí nada en los pasos 1 a 10 cuando cambié el paso 5". Las pruebas de regresión son instantáneas
Surgen mejores diseños : He encontrado mejores diseños emergentes sin que yo invierta el esfuerzo en una actividad de diseño. test-first + Refactoring conduce a clases mínimas poco acopladas con métodos mínimos ... sin ingeniería excesiva ... sin código YAGNI. Las clases tienen mejores interfaces públicas, métodos pequeños y son más legibles. Esto es una especie de cosa zen ... solo notas que lo tienes cuando lo 'obtienes'.
El depurador ya no es mi muleta : sé lo que hace mi programa ... sin tener que pasar horas leyendo mi propio código. Hoy en día si paso más de 10 minutos con el depurador ... las alarmas mentales comienzan a sonar.
Me ayuda a ir a casa a tiempo He notado una marcada disminución en la cantidad de errores en mi código desde TDD ... incluso si la afirmación es como un seguimiento de la Consola y no un tipo AT de xUnit.
Productividad / Flujo : me ayuda a identificar el próximo paso discreto que me llevará hacia el final ... mantiene la bola de nieve rodando. TDD me ayuda a entrar en un ritmo (o lo que los XPers llaman flujo) más rápido. Obtuve una mayor cantidad de trabajo de calidad realizado por unidad de tiempo que antes. El ciclo refactor rojo-verde se convierte en ... una especie de máquina de movimiento perpetuo.
Puedo demostrar que mi código funciona con solo tocar un botón
La práctica hace la perfección Me encuentro aprendiendo & amp; detectar dragones más rápido ... con más tiempo TDD en mi haber. Tal vez disonancia ... pero siento que TDD me ha convertido en un mejor programador incluso cuando no voy a probar primero. Detectar oportunidades de refactorización se ha convertido en una segunda naturaleza ...

Actualizaré si pienso en algo más ... esto es lo que se me ocurrió en los últimos 2 minutos de reflexión.

También soy programador por contrato. Aquí están mis 12 razones por las que amo las pruebas unitarias .

Mi mejor experiencia con TDD se centra en el proyecto pyftpdlib . La mayor parte del desarrollo es realizada por el autor original, y he hecho algunas pequeñas contribuciones, pero es esencialmente un proyecto en solitario. El conjunto de pruebas para el proyecto es muy completo y prueba todas las características principales de la biblioteca FTPd. Antes de registrar los cambios o lanzar una versión, se verifican todas las pruebas, y cuando se agrega una nueva característica, el conjunto de pruebas siempre se actualiza.

Como resultado de este enfoque, este es el único proyecto en el que he trabajado que no tuvo errores aparentes después de una nueva versión, se revisaron los cambios que rompieron una característica importante, etc. El código es muy sólido y me ha impresionado constantemente la poca cantidad de informes de errores que se han abierto durante la vida del proyecto. Yo (y el autor original) atribuimos gran parte de este éxito al conjunto completo de pruebas y la capacidad de probar cada ruta de código importante a voluntad.

Desde una perspectiva lógica, cualquier código que escriba debe probarse, y sin TDD, lo probará usted mismo manualmente. Por otro lado, pyftpdlib, el peor código por número de errores y frecuencia de problemas importantes, es el código que está siendo / solo probado por los desarrolladores y QA probando nuevas características manualmente. Las cosas no se ponen a prueba debido a la falta de tiempo o la caída de las grietas. Las rutas de código antiguas se olvidan e incluso las características estables más antiguas terminan por romperse, las versiones principales terminan con características importantes no funcionales. etc. Las pruebas manuales son de importancia crítica para la verificación y la aleatorización de las pruebas, pero según mi experiencia, diría que es esencial contar con pruebas manuales y un marco de pruebas unitarias cuidadosamente construido. Entre los dos enfoques, las brechas en la cobertura son menores, y su probabilidad de problemas solo puede reducirse.

No importa si usted es el único desarrollador o no. Tienes que pensarlo desde el punto de vista de la aplicación. Todas las aplicaciones deben funcionar correctamente, todas las aplicaciones deben mantenerse, todas las aplicaciones deben tener menos errores. Por supuesto, hay ciertos escenarios en los que un enfoque TDD podría no ser adecuado para usted. Esto es cuando la fecha límite se acerca muy rápido y no hay tiempo para realizar pruebas unitarias.

De todos modos, TDD no depende de un entorno individual o de equipo. Depende de la aplicación en su conjunto.

No tengo una gran cantidad de experiencia, pero he tenido la experiencia de ver enfoques de prueba muy contrastados.

En un trabajo, no hubo pruebas automatizadas. " Prueba " consistía en hurgar en la aplicación, probando lo que se te ocurría, para ver si se rompía. No hace falta decir que fue fácil para el código roto llegar a nuestro servidor de producción.

En mi trabajo actual, hay muchas pruebas automatizadas y un sistema CI completo. Ahora, cuando el código se rompe, es inmediatamente obvio. No solo eso, sino que mientras trabajo, las pruebas realmente documentan qué características están funcionando en mi código y cuáles no. Me da mucha confianza poder agregar nuevas funciones, sabiendo que si rompo las existentes, no pasaré desapercibido.

Entonces, para mí, no depende tanto del tamaño del equipo, sino del tamaño de la aplicación. ¿Puedes hacer un seguimiento de cada parte de la aplicación? Cada requisito? ¿Cada prueba que necesita ejecutar para asegurarse de que la aplicación funciona? ¿Qué significa incluso decir que la aplicación está & Quot; funcionando & Quot ;, si no tiene pruebas para demostrarlo?

Solo mis $ 0.02.

Las pruebas le permiten refactorizar con la confianza de que no está rompiendo el sistema. Escribir las pruebas primero permite que las pruebas definan cuál es el comportamiento de trabajo del sistema. Cualquier comportamiento que no esté definido por la prueba es, por definición, un subproducto y se le permite cambiar cuando se refactoriza. Las pruebas de escritura primero también conducen el diseño en buenas direcciones. Para admitir la capacidad de prueba, encontrará que necesita desacoplar clases, usar interfaces y seguir un buen patrón (Inversión de control, por ejemplo) para que su código sea fácilmente comprobable. Si escribe pruebas después, no puede estar seguro de que ha cubierto todo el comportamiento esperado de su sistema en las pruebas. También encuentra que algunas cosas son difíciles de probar debido al diseño, ya que probablemente se desarrolló sin tener en cuenta las pruebas, y están tentados a escatimar u omitir las pruebas.

Generalmente trabajo solo y sobre todo hago TDD: los casos en los que no lo hago son simplemente donde no cumplo con mis prácticas o aún no he encontrado una buena manera que me sirva para hacer TDD, por ejemplo con interfaces web.

TDD no se trata de probar, se trata de escribir código. Como tal, proporciona muchos beneficios incluso para un solo desarrollador. Para muchos desarrolladores es un cambio mental escribir código más robusto. Por ejemplo, ¿con qué frecuencia piensa & Quot; Ahora, ¿cómo puede fallar este código? & Quot; después de escribir código sin TDD? Para muchos desarrolladores, la respuesta a esa pregunta es ninguna. Para los practicantes de TDD, cambia la mentalidad a hacer cosas como verificar si los objetos o las cadenas son nulos antes de hacer algo con ellos porque estás escribiendo pruebas para hacerlo específicamente (descifrar el código).

Otra razón importante es el cambio. Cada vez que trata con un cliente, parece que nunca se deciden. Lo único constante es el cambio. TDD ayuda como & "; Red de seguridad &"; para encontrar todas las otras áreas que podrían romperse. Incluso en proyectos pequeños, esto puede evitar que gaste un tiempo precioso en el depurador.

Podría seguir y seguir, pero creo que decir que TDD tiene más que ver con escribir código que con cualquier otra cosa debería ser suficiente para justificar su uso como desarrollador exclusivo.

Tiendo a estar de acuerdo con la validez de su punto sobre los gastos generales de TDD para proyectos de 'un desarrollador' o 'pasatiempo' que no justifican los gastos.

Sin embargo, debe tener en cuenta que la mayoría de las mejores prácticas son relevantes y útiles si se aplican de manera constante durante un largo período de tiempo.

Por ejemplo, TDD le ahorra tiempo de prueba / corrección de errores a largo plazo, no dentro de los 5 minutos posteriores a la creación de la primera prueba unitaria.

Eres un programador por contrato, lo que significa que dejarás tu proyecto actual cuando esté terminado y cambiarás a otra cosa, muy probablemente en otra compañía. Su cliente actual tendrá que mantener y respaldar su aplicación. Si no deja al equipo de soporte un buen marco para trabajar, se quedarán estancados. TDD ayudará al proyecto a ser sostenible. Aumentará la estabilidad de la base de código para que otras personas con menos experiencia no puedan hacer demasiado daño al tratar de cambiarla.

Lo mismo se aplica a los proyectos de pasatiempo. Es posible que esté cansado de ello y desee pasarlo a alguien. Es posible que tenga éxito comercial (piense en Craiglist) y tendrá 5 personas más trabajando además de usted.

La inversión en el proceso adecuado siempre vale la pena, incluso si solo se gana experiencia. Pero la mayoría de las veces estarás agradecido de que cuando comenzaste un nuevo proyecto decidiste hacerlo correctamente

Tienes que considerar a OTROS personas al hacer algo. Debe pensar en el futuro, planificar el crecimiento , planificar la sostenibilidad .

Si no quieres hacer eso, sigue la codificación del vaquero, es mucho más simple de esta manera.

P.S. Lo mismo se aplica a otras prácticas:

Si no comenta su código y tiene una memoria ideal, estará bien, pero alguien más que lea su código no lo hará.
Si no documenta sus conversaciones con el cliente, otra persona no sabrá nada sobre una decisión crucial que haya tomado

etc ad infinitum

Ya no refactorizo nada sin un conjunto razonable de pruebas unitarias.

No hago TDD completo con pruebas unitarias primero y código después.Hago CALTAL - Codifica un poco, prueba un poco - desarrollo.Generalmente, el código va primero, pero no siempre.

Cuando descubro que tengo que refactorizar, me aseguro de tener suficientes pruebas y luego modifico la estructura con total confianza de que no tengo que conservar toda la arquitectura antigua que se convierte en arquitectura nueva. plan en mi cabeza.Sólo tengo que volver a pasar las pruebas.

Refactorizo las partes importantes.Haga pasar el conjunto de pruebas existente.

Entonces me doy cuenta de que olvidé algo y vuelvo al desarrollo de CALTAL con las cosas nuevas.

Luego veo cosas que olvidé eliminar, pero ¿están en realidad sin usar en todas partes?Elimínelos y vea qué falla en la prueba.

Ayer mismo, a mitad de una gran refactorización, me di cuenta de que todavía no tenía exactamente el diseño correcto.Pero las pruebas aún tenían que pasar, por lo que era libre de refactorizar mi refactorización incluso antes de terminar con la primera refactorización.(¡Uf!) Y todo funcionó muy bien porque tenía un conjunto de pruebas para validar los cambios.

Para volar solo, TDD es mi copiloto.

TDD me permite definir más claramente el problema en mi cabeza. Eso me ayuda a concentrarme en implementar solo la funcionalidad que se requiere y nada más. También me ayuda a crear una API mejor, porque estoy escribiendo un & Quot; client & Quot; antes de escribir el código en sí. También puedo refactorizar sin tener que preocuparme por romper nada.

Voy a responder esta pregunta bastante rápido, y espero que empieces a ver algunos de los razonamientos, incluso si aún no estás de acuerdo. :)

Si tiene la suerte de estar en un proyecto de larga duración, habrá momentos en los que quiera, por ejemplo, escribir primero su nivel de datos, luego quizás el nivel de negocios, antes de avanzar en la pila. Si su cliente realiza un cambio de requisitos que requiere volver a trabajar en su capa de datos, un conjunto de pruebas unitarias en la capa de datos garantizará que sus métodos no fallen de manera indeseable (suponiendo que actualice las pruebas para reflejar los nuevos requisitos ) Sin embargo, es probable que también llame al método de la capa de datos desde la capa empresarial, y posiblemente en varios lugares.

Supongamos que tiene 3 llamadas a un método en la capa empresarial, pero solo modifica 2. En el tercer método, aún puede recuperar datos de su capa de datos que parecen ser válidos, pero pueden romper algunos de los supuestos que codificó meses antes. Las pruebas unitarias a este nivel (y superiores) deberían haber sido diseñadas para detectar supuestos rotos, y al fallar deberían resaltar que hay una sección de código que debe revisarse.

Espero que este ejemplo tan simple sea suficiente para hacerle pensar un poco más sobre TDD, y que pueda crear una chispa que lo haga considerar usarlo. Por supuesto, si todavía no ve el punto y confía en sus propias habilidades para realizar un seguimiento de miles de líneas de código, entonces no tengo lugar para decirle que debe comenzar TDD.

El punto sobre escribir las pruebas primero es que hace cumplir los requisitos y las decisiones de diseño que está tomando. Cuando modifico el código, quiero asegurarme de que se sigan aplicando y que sea lo suficientemente fácil como & Quot; break & Quot; algo sin obtener un compilador o error en tiempo de ejecución.

Tengo un enfoque de prueba primero porque quiero tener un alto grado de confianza en mi código. De acuerdo, las pruebas deben ser buenas o no imponen nada.

Tengo algunas bases de código bastante grandes en las que trabajo y hay muchas cosas no triviales. Es bastante fácil hacer cambios que se agitan y de repente X ocurre cuando X nunca debería suceder. Mis pruebas me han salvado en varias ocasiones de cometer un error crítico (pero sutil) que podría pasar desapercibido para los evaluadores humanos.

Cuando las pruebas fallan, son oportunidades para mirarlas y el código de producción y asegurarse de que sean correctas. A veces, el diseño cambia y las pruebas deberán modificarse. A veces escribo algo que pasa 99 de 100 pruebas. Esa 1 prueba que no pasó es como un compañero de trabajo revisando mi código (en cierto sentido) para asegurarse de que todavía estoy construyendo lo que se supone que estoy construyendo.

Siento que, como desarrollador en solitario de un proyecto, especialmente uno más grande, tiende a extenderse bastante.
Está en medio de una gran refactorización cuando, de repente, se detectan un par de errores críticos que por alguna razón no aparecieron durante las pruebas previas al lanzamiento. En este caso, debe soltar todo y arreglarlo, y después de pasar dos semanas arrancándose el cabello, finalmente puede volver a lo que estaba haciendo antes.
Una semana después, uno de sus clientes más grandes se da cuenta de que deben tener esta nueva característica brillante o, de lo contrario, no realizarán el pedido de esas unidades de 1 millón que ya deberían haber pedido hace un mes.
Ahora, tres meses después, ni siquiera recuerda por qué comenzó a refactorizar en primer lugar, mucho menos qué se suponía que debía hacer el código que está refactorizando. Gracias a Dios que hiciste un buen trabajo escribiendo esas pruebas unitarias porque al menos te dicen que tu código refactorizado sigue haciendo lo que se suponía que debía hacer.
Espuma, enjuague, repita.

.. historia de mi vida durante los últimos 6 meses. : - /

El desarrollador único debe usar TDD en su proyecto (el historial no importa), ya que eventualmente este proyecto podría pasarse a otro desarrollador. O se podrían traer más desarrolladores.

A las personas nuevas les resultará extremadamente difícil trabajar con el código sin las pruebas. Romperán las cosas.

¿Su cliente posee el código fuente cuando entrega el producto? Si puede convencerlos de que entregar el producto con pruebas unitarias agrega valor, entonces está vendiendo sus servicios y ofreciendo un mejor producto. Desde la perspectiva del cliente, la cobertura de prueba no solo garantiza la calidad, sino que permite a los futuros encargados de la comprensión comprender el código mucho más fácilmente, ya que las pruebas aíslan la funcionalidad de la interfaz de usuario.

Creo que TDD como metodología no se trata solo de & "; tener pruebas al hacer cambios &"; por lo tanto, no depende del equipo ni del tamaño del proyecto. Se trata de observar las expectativas de uno sobre lo que hace una porción de código / aplicación ANTES de que uno empiece a pensar realmente en CÓMO se implementa el comportamiento observado. El enfoque principal de TDD no es solo tener una prueba para el código escrito, sino escribir menos código porque solo haces lo que hace que la prueba sea verde (y la refactorice más adelante).

Si eres como yo y te resulta bastante difícil pensar en lo que hace una parte / toda la aplicación SIN pensar en cómo implementarla, creo que está bien escribir tu prueba después de tu código y así permitir que el código < !> quot; conducir " las pruebas.

Si su pregunta no es tanto sobre prueba primero (TDD) o prueba después (¿buena codificación?) Creo que las pruebas deberían ser una práctica estándar para cualquier desarrollador, ya sea solo o en un gran equipo, que crea código que permanece en producción por más de tres meses. En mi experiencia, ese es el lapso de tiempo después del cual incluso el autor original tiene que pensar mucho sobre lo que realmente hacen estas veinte líneas de código complejo, súper optimizado pero escasamente documentado. Si tiene pruebas (que cubren todas las rutas a través del código), hay menos para pensar y menos para ERR, incluso años después ...

Aquí hay algunos memes y mis respuestas:

& "; TDD me hizo pensar en cómo fallaría, lo que me convirtió en un mejor programador &";

Dada la experiencia suficiente, estar muy preocupado por los modos de falla debería, naturalmente, formar parte de su proceso de todos modos.

" Las aplicaciones deben funcionar correctamente "

Esto supone que puede probar absolutamente todo. En primer lugar, no será mejor para cubrir todas las pruebas posibles correctamente que para escribir el código funcional correctamente. " Las aplicaciones deben funcionar mejor " Es un argumento mucho mejor. Estoy de acuerdo con eso, pero es idealista y no tan tangible como para motivarme tanto como desearía. Las métricas / anécdotas serían geniales aquí.

" Funcionó muy bien para mi < componente de biblioteca X > "

Dije en la pregunta que vi valor en estos casos, pero gracias por la anécdota.

" Piense en el próximo desarrollador "

Este es probablemente uno de los mejores argumentos para mí. Sin embargo, es muy probable que el próximo desarrollador tampoco practique TDD y, por lo tanto, sería un desperdicio o incluso una carga en ese caso. Evangelismo de puerta trasera es lo que equivale a eso. Sin embargo, estoy bastante seguro de que un desarrollador de TDD realmente lo agradecería.

¿Cuánto va a apreciar los proyectos realizados en metodologías obsoletas cuando hereda una? RUP, alguien? Piense en lo que significa TDD para el próximo desarrollador si TDD no es tan bueno como todos piensan que es.

" Refactorizar es mucho más fácil "

La refactorización es una habilidad como cualquier otra, y el desarrollo iterativo ciertamente requiere esta habilidad. Tiendo a tirar cantidades considerables de código si creo que el nuevo diseño ahorrará tiempo a largo plazo, y parece que también se tirarán una cantidad terrible de pruebas. ¿Cuál es más eficiente? No lo se.

...

Probablemente recomendaría algún nivel de TDD a cualquier persona nueva ... pero todavía tengo problemas con los beneficios para cualquiera que ya haya estado en la cuadra varias veces. Probablemente comenzaré a agregar pruebas automatizadas a las bibliotecas. Es posible que después de hacer eso, vea más valor hacerlo en general.

Interés propio motivado.

En mi caso, el desarrollador exclusivo se traduce como propietario de una pequeña empresa. He escrito una cantidad razonable de código de biblioteca para (aparentemente) hacerme la vida más fácil. Muchas de estas rutinas y clases no son ciencia espacial, por lo que puedo estar bastante seguro de que funcionan correctamente (al menos en la mayoría de los casos) al revisar el código, algunas pruebas puntuales y la depuración de los métodos para asegurarse de que se comporten de la manera correcta. Creo que si. Fuerza bruta, si quieres. La vida es buena.

Con el tiempo, esta biblioteca crece y se utiliza en más proyectos para diferentes clientes. Las pruebas requieren más tiempo. Especialmente casos donde estoy (con suerte) arreglando errores y (aún más con suerte) no estoy rompiendo otra cosa. Y esto no es solo para errores en mi código. Tengo que tener cuidado al agregar funcionalidad (los clientes siguen pidiendo más & Quot; cosas & Quot;) o asegurándome de que el código aún funciona cuando se mueve a una nueva versión de mi compilador (Delphi!), Código de terceros, tiempo de ejecución entorno o sistema operativo.

Llevado al extremo, podría pasar más tiempo revisando el código antiguo que trabajando en proyectos nuevos (léase: facturables). Piense en ello como el ángulo de reposo del software (qué tan alto puede apilar el software no probado antes de que se caiga :).

Técnicas como TDD me dan métodos y clases que están más cuidadosamente diseñados, más probados (antes de que el cliente los obtenga) y necesitan menos mantenimiento en el futuro.

En última instancia, se traduce en menos tiempo de mantenimiento y más tiempo para hacer cosas que son más rentables, más interesantes (casi cualquier cosa) y más importantes (como la familia).

Todos somos desarrolladores con un buen historial. Después de todo, todos estamos leyendo Stackoverflow. Y muchos de nosotros usamos TDD y tal vez esas personas tienen un gran historial. Me contratan porque la gente quiere a alguien que escriba una gran automatización de pruebas y pueda enseñar eso a otros. Cuando trabajo solo, hago TDD en mis proyectos de codificación en casa porque descubrí que si no & # 8217; t, pasaba el tiempo haciendo pruebas manuales o incluso depurando, y quién lo necesita. (Quizás esas personas solo tienen buenos registros de seguimiento. Yo no & # 8217; lo sé).

Cuando se trata de ser un buen conductor, todos creen que son & # 8220; buen conductor. & # 8221; Este es un sesgo cognitivo que tienen todos los conductores. Los programadores tienen sus propios prejuicios. Las razones por las cuales los desarrolladores, como OP, no & # 8217; t do TDD están cubiertos en este serie de podcast Agile Thoughts . El archivo de podcast también tiene contenido sobre conceptos de automatización de pruebas como prueba de la pirámide , y una introducción sobre qué es TDD y por qué escribir las pruebas primero comenzando con el episodio 9 en el archivo de podcast .

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow