¿Cómo es que, a fines de 2014, todavía hay muchos desarrolladores de software que piensan que las pruebas unitarias son una pérdida de tiempo?

• Las malas prácticas de gestión a menudo fomentan los malos hábitos.

  He visto a muchos gerentes insistir en un cierto umbral de cobertura del código de prueba unitaria, pero nunca revisan una sola línea de código de prueba. Esto lleva a malas pruebas y los ingenieros que las escriben lo saben. Estos ingenieros elegirán con razón no escribir malas pruebas en el futuro si se les da una oportunidad.

  Muchos gerentes no logran crear estrategias integrales de aseguramiento de la calidad que abarquen las pruebas unitarias a través de las pruebas de integración de pila completa hasta las pruebas de rendimiento. En cambio, apagan incendios a medida que surgen, lo que lleva a un enfoque obvio en hacer que funcione sobre la creación de software de calidad.

  Los gerentes a menudo elogian y promueven a los ingenieros que trabajan arduamente y que constantemente arreglan sus aplicaciones rotas sobre los ingenieros cuyas aplicaciones funcionan desde el principio.

• Algunos lenguajes / marcos hacen que las pruebas de unidad / integración sean más fáciles que otras.

  La mayoría de los desarrolladores tienen experiencia con paradigmas de desarrollo en los que las pruebas son más una ocurrencia tardía que una característica de primera clase.

  ¿Estás trabajando con Ruby on Rails? Entonces las pruebas son fáciles y predeterminadas. ¿Su aplicación es una mezcla de bibliotecas Java? Entonces tendrá que descubrir cómo escribir buenas pruebas de unidad por su cuenta y no será bonito (¿alguna vez miró el código de inyección de dependencia?).

  ¿Estás trabajando con un montón de código heredado? Poner en marcha una estrategia de prueba efectiva para el código antiguo puede ser realmente difícil.

• Una buena parte de los desarrolladores simplemente nunca lo han visto bien.

  Han escuchado hablar de eso, pero se las han arreglado bien en sus carreras sin él. ¿Por qué cambiar ahora? Llevan consigo suposiciones sobre las pruebas unitarias, como que deben aumentar el tiempo de desarrollo, lo que probablemente sea cierto a lo largo de sus carreras porque están trabajando con lenguajes / marcos que no tienen un gran apoyo para las pruebas bajo regímenes de gestión que no saben cómo alentar prueba de artesanía efectiva.

Porque como cualquier otra cosa, cuando se hace sin pensar, las pruebas unitarias son una pérdida de tiempo.

Las pruebas unitarias cuestan tiempo para crear, el tiempo de ejecución y el tiempo de reparación cuando cambian los requisitos. Las pruebas de unidad incorrectas también cuestan tiempo cuando se modifican detalles menores de implementación, o cuando los cambios de alguna otra unidad se filtran a esta unidad, y tal vez algo sin importancia ha cambiado ligeramente.

Cuando las pruebas son forzadas, obtienes malas pruebas; Cuando el 85% de las pruebas que un desarrollador ve son malas, podría extrapolar a “las pruebas son una pérdida de tiempo”.