Recientemente me encontré con este problema cuando un cliente estaba de acuerdo con nuestra metodología, pero la administración superior se dio cuenta de que los desarrolladores pasaban el tiempo probando en lugar de desarrollarse y estaban preocupados por esto. Después de todo, tenían personal de control de calidad que hacer. ¡la prueba! Hice un blog sobre cómo lidié con esto aquí:

enlace

Para resumir, comparé nuestras horas estimadas con las horas reales para el proyecto y luego comparé nuestra tasa de defectos con la tasa de defectos de otros equipos. En nuestro caso, estas cifras se compararon favorablemente y no hubo más preocupaciones.

Mi conclusión basada en esta experiencia es:

  

... la mejor manera de convencer a cualquier persona de que tu enfoque para hacer algo es práctico y pragmático, es hacerlo y medirlo con respecto a otros enfoques. A las personas no les importa el dogma, o ¿Por qué crees que algo debería ser la mejor manera? Solo mostrando a las personas los números y midiendo la efectividad de su enfoque, podrá demostrar verdaderamente que sus prácticas son efectivas.

En otros proyectos, hemos trabajado junto con desarrolladores de clientes que no crearon pruebas unitarias o hicieron TDD y tuvimos que mantener las pruebas que rompen. Sin embargo, se vuelve muy fácil vender el enfoque TDD a esos desarrolladores clientes cuando puedes decirles lo que han roto en el código antes de que sepan.

Por lo tanto, en su caso, lo haría a escondidas si es necesario (tal vez haya un área pequeña del código que pueda comenzar a probar y que cambie con frecuencia o de la que sea responsable), pero haga un seguimiento de tus números : ¿cuál es el esfuerzo para crear tus pruebas? ¿Cuál es la tasa de defectos? ¿Cómo se compara esto con otros proyectos / miembros del equipo?

En mi opinión, nadie debería pedir permiso o disculparse por querer hacer su trabajo correctamente y cualquier desarrollador profesional debería intentar probar su código con pruebas automatizadas siempre que sea posible y práctico. Esperemos que sea ambas cosas en tu caso. Buena suerte!

Mostrar el retorno de la inversión (ROI)

Escribir pruebas automatizadas lleva tiempo. Una vez. La ejecución de pruebas automatizadas lleva cero tiempo, porque puede hacer otra cosa mientras se están ejecutando.

Ejemplo: la función de prueba manual X lleva 30 minutos. Escribir una prueba automatizada para ello tomaría 1 hora. Incluso si no tenemos errores, tendremos que probar la característica X diez veces durante el curso del proyecto a medida que se modifiquen sus capas y componentes dependientes. Por lo tanto, la automatización de la prueba de la característica X nos ahorrará 4 horas durante la vida del proyecto.

En realidad, es cuando tienes un error que las pruebas automatizadas realmente dan resultado. Primero, encuentran errores de manera temprana y económica, lo que ahorra tiempo y vergüenza. En segundo lugar, si tienes un error difícil y pasas por muchos ciclos de prueba de creación de código para resolverlo, el tiempo ahorrado en las pruebas manuales se suma extraordinariamente rápido.

Las empresas entienden ahorrar tiempo y dinero. Así es como venderlo.

Si ya los has confrontado, y no están de acuerdo con eso, pero no te sientes cómodo escribiendo código sin ellos ... entonces no vuelvas a preguntar. Simplemente escríbalos y no los registre.

La administración no va a contar las líneas de código, pero verán que todos sus registros tienen tasas de aprobación más altas de control de calidad (o clientes) y eventualmente preguntarán por qué ... entonces puede ser como " ¡BAM! ¡TDD! "

No estás jugando con el proyecto, proceso o fuente ... así que no veo una razón negativa. Honestamente, no veo una razón por la que sea diferente en cuanto al tiempo que ejecutar todas las pruebas de resultados de ejecución + entrada + verificación manual.

1) El cliente no pagó las pruebas unitarias

El cliente (pensó que) pagó por una solución de trabajo. Dependiendo de los defectos contractuales, la reparación puede ser rentable para su empresa. Si hay suficiente seguridad, vuelva a pagar por una solución que funcione. TDD debería ayudar a ese objetivo.

2) El proyecto no da tiempo para TDD

TDD no lleva más tiempo. Debería reducir la cantidad de código extraño o superfluo y enfocar la base de código en lo que hace que las pruebas pasen. Todas las pruebas que pasan, sujetas a la calidad de la prueba y lo apropiado, significan que el código está listo.

3) ¿Deuda técnica? ¿Qué deuda técnica?

Me da la impresión de que podría estar argumentando para agregar retrospectivamente pruebas al código existente. Esta es una pesadilla que se vende en el mejor momento y no brinda los beneficios que podría esperar. Sin embargo, agregar pruebas a medida que solucione los errores debería ser aceptable y ayudar a largo plazo.

No recomiendo escribir las pruebas de todos modos como Snorfus ha sugerido. Suena bien en teoría, pero las pruebas unitarias pueden y sí cambian con el tiempo. A medida que cambian los requisitos, se agregan nuevas funciones, las pruebas unitarias deben actualizarse. Si trabaja como parte de un equipo, sus pruebas de unidad quedarán desactualizadas a medida que otros agreguen funciones / correcciones.

Estoy abordando los puntos específicos que mencionaste en lugar de plantear otros nuevos porque hay mucho camino para avanzar o entender por qué se está bloqueando.

Para cada cliente frente a problemas de producción,

1. Escriba una prueba de unidad y envíe un correo electrónico al gerente diciendo que Usted han agregado una prueba de unidad para cubrir el escenario.

2. Y dígale que este problema no volverá a ocurrir en la producción. Porque nuestra prueba de unidad se ejecuta todas las noches y llegaremos a conocerla. Antes de que el código entre en producción mirando esta prueba de unidad. falla.

3. Dígale que si ya hicimos esta prueba de unidad antes de la código fue a producción, este problema de producción nunca habría sucedió.

Haz esto de manera consistente y persistente y pronto estará convencido. A los gerentes no les gusta que el cliente se enfrente a los problemas de producción y él aceptará la idea de prueba de la Unidad. Buena suerte.