¿Cómo puedo comenzar a probar en un anticultivo de prueba? [cerrado]

Tengo una confesión que hacer: las pruebas automatizadas formalizadas nunca fueron parte de mi experiencia en programación. Ahora trabajo en una empresa muy grande con muchos desarrolladores (la mayoría de ellos desarrolladores web de un tipo u otro), y es evidente que la mayoría de ellos tampoco prueba *. (* No voy a seguir diciendo formalmente ; infiéralo).

Si espero tener el apoyo de mi organización para comenzar a probar, nunca sucederá. Si trato de "cambiar las cosas desde adentro" empujando las pruebas en la gerencia, se me acabará el vapor antes de que ocurra el cambio. Necesito comenzar a probar ahora.

Pero con TDD y su tipo, terminaré con un montón de código de prueba junto con el código de producción. Nuestros sistemas de control de versiones (todos centralizados) no están organizados para almacenar el código de prueba. Tendré que encontrar un lugar para todo eso en mi estación de trabajo.

¿Es posible comenzar una práctica personal de pruebas de software en una cultura que no valora ni proporciona las herramientas para ello? ¿Qué técnicas y herramientas utiliza para permitirle probar cuando las herramientas y la organización oficiales no tienen lugar para pruebas, marcos y automatizaciones?

Personalmente hice esto con considerable éxito. Los factores clave para el éxito:

• Obtenga (provisional) soporte de gestión. Las ventajas de las pruebas automatizadas están bien documentadas y deberían convencer a cualquier gerente para que al menos lo intente. Eso incluye encontrar un lugar en el VCS y un servidor de compilación, porque
• Las pruebas automatizadas solo brindan su valor total si se ejecutan con frecuencia y de manera automática, para que pueda conocer los problemas pronto y no tenga que confiar en que las personas no se olviden de ejecutarlos. Necesita un servidor de compilación que los ejecute al menos diariamente. Esta puede ser una vieja estación de trabajo. Jenkins necesita muy poco trabajo para correr.
• Predicar con el ejemplo. Escriba pruebas, hable sobre el beneficio que le están brindando y cuando revelen errores introducidos por otros desarrolladores, hable sobre esto en términos de cómo estaban protegidos de una vergüenza potencialmente mucho mayor.
• Ir por la fruta baja. Algunas partes de la aplicación serán difíciles de probar, otras fáciles. Algunos serán robustos, otros frágiles. Escribir pruebas para piezas frágiles, pero fáciles de probar, proporciona el mayor valor en el menor tiempo.
• Vea si puede escribir pruebas reutilizables, por ejemplo, las convenciones o características de prueba que todos los módulos (páginas web, servicios REST, lo que sea) deben tener pero que a menudo se olvida.

Sin el apoyo de la gerencia, estás muerto en el agua. La gerencia alegará que no está haciendo un trabajo que valga la pena, será penalizado en sus revisiones y finalmente será despedido. Hay maneras de hacer que la administración vea que las pruebas tempranas les cuestan menos y todo eso. Es posible cambiar la cultura, pero estás poniendo el cuello en el tajo.

Sugeriría leer el capítulo de Maquiavelo El Príncipe sobre cómo introducir el cambio antes de hacer algo.

En mi experiencia, si la cultura es anti-prueba, no se puede presentar razonablemente. O bien, las pruebas se considerarán una pérdida de tiempo y se lo reprendió por "perder el tiempo" o "tomar demasiado tiempo", o el código se ha infectado por años de no haber sido escrito de manera comprobable (por ejemplo, sin interfaces, todo estrechamente acoplado) y tendrá que pasar mucho tiempo refactorizando y / o reescribiendo código (por lo tanto, corre el riesgo de "tomar demasiado tiempo" y "perder el tiempo") para que sea comprobable y pueda escribir pruebas en primer lugar .

Puede tener una oportunidad si está haciendo cosas nuevas que solo tienen que interactuar con cosas existentes (cree un buen envoltorio alrededor de las áreas malas) o si puede hacerlo en pequeñas cantidades donde no causará problemas o requerirá que lo haga. "trabajar en tareas que no te han sido asignadas" que pueden ubicarte en la caseta del perro.

No creo que llegue muy lejos hasta que pueda establecer un caso lo suficientemente bueno como para que haya un problema (que puede no ser reconocido actualmente) que las pruebas automáticas puedan abordar.

Si existe una cultura de pruebas manuales contra scripts definidos, entonces hay un costo de ejecutar esos scripts junto con un riesgo de resultados incompletos o inexactos. Puede haber una historia (documentada o en forma de "historia de guerra") de esto. Sugiera un proyecto piloto para automatizar algunas de esas pruebas manuales con el fin de ofrecer un ahorro de costos a largo plazo.

Si ni siquiera hay una función de prueba manual, sugeriría que la empresa no perciba que cualquier tipo de prueba formal, automatizada o no, tiene valor. En ese caso, consideraría que el camino por recorrer es largo y abruptamente cuesta arriba, pero nuevamente es probable que necesite una demostración clara de que el negocio puede beneficiarse al adoptar un enfoque menos informal de la calidad del software. Si no puede hacer eso, entonces es difícil ver cómo podría haber algún apoyo para la idea por motivos comerciales.

Una idea es que su objetivo es escribir una prueba que demuestre que el código que alguien más ha escrito es defectuoso. Debería vender el concepto.