¿Cómo comenzar el hábito de escribir la prueba unitaria como empleado? (o debería?) [duplicar]

Los buenos hábitos de codificación comienzan en casa.

En serio, hasta que seas bueno en eso, mantenlo en casa. Mira, todo el mundo prueba su código. La prueba unitaria es una forma de automatizar esa prueba. Si cree que se trata de obtener tiempo adicional para dedicar a las pruebas, no está listo. Estarás listo cuando estés escribiendo pruebas unitarias porque te ahorran tiempo.

Esto no tiene nada que ver con tu jefe. De hecho, su jefe nunca tiene que ver sus pruebas. Hasta que su tienda llegue a las pruebas unitarias, puede mantenerlas en su propia sucursal de control de fuente local. No es necesario que se los muestres a nadie.

Si desea popularizar las pruebas de unidad en su oficina, la forma de hacerlo es ser lo suficientemente bueno como para ser el tipo cuyo código es más rápido y más libre de errores que cualquier otra persona. Hasta que seas ese tipo, hablar de esto solo te convertirá en el tipo molesto que intenta retrasarnos.

Si eres el único que lo hace, será mejor que lo enseñes antes de difundirlo. O puede atascar las obras mientras otros lo arruinan y dejan que el jefe se pregunte de dónde vino esta idea tan tonta de prueba de unidad.

Las pruebas unitarias y TDD son disciplinas efectivas. No los uses en la fe. Cuando seas lo suficientemente bueno para usarlos correctamente, no necesitarás un hábito. No necesitas justificarlos. Solo los alcanzarás porque te enfrentas a algo difícil y sabes que esta es la forma más fácil de salir.

Hasta que seas tan bueno, no les des una mala reputación probándolos en el trabajo demasiado pronto.

Lamentablemente, no creo que haya una respuesta fácil a tu pregunta. Debería ser bastante fácil encontrar algo que aislar para la prueba, por ejemplo. Algunos módulos tienen pocas dependencias, pero es difícil mostrar los beneficios inmediatos de las pruebas. Los beneficios generalmente se muestran en un producto más robusto y fácil de mantener, con menos errores.

Un problema con las pruebas unitarias es que a pesar de que muestran que si algo se rompe en una unidad, no necesariamente detectan los errores que las pruebas de aceptación o las pruebas de integración atraparían y sus esfuerzos no convencerán a la administración para que adopte las pruebas porque su aplicación se rompe de todos modos. Hay muchas maneras de equivocarse cuando recién estás comenzando.

Sin embargo, tocas un punto importante. Es importante que su equipo y administración se unan a las pruebas.

Al final, debe encontrar una forma de demostrarle a la administración que le cuesta a la empresa los ingresos, entonces estarán más inclinados a escuchar. Estoy de acuerdo con quienes abogan por el enfoque diplomático y, si eso no funciona, es posible que la empresa no se encuentre en una etapa en la que adopte las pruebas.

A diferencia de otros, quiero que seas ese tipo molesto que ralentiza las cosas. En primer lugar, porque no estoy de acuerdo con que esté desacelerando las cosas al querer mejorar el rendimiento del equipo, pero las consecuencias de hacerlo por su cuenta son, en mi opinión, peores. Un equipo donde todos hacen las cosas por su cuenta solo para (quizás) mostrar lo que han hecho mucho más tarde, qué pesadilla.

Para comenzar a escribir las pruebas unitarias, hable sobre el asunto con su gerente y le pide que haga las pruebas unitarias de escritura como parte de su trabajo. Y cuando él o ella hace que las pruebas de unidad de escritura sean parte de su trabajo, usted escribe pruebas de unidad. Si no es parte de tu trabajo, no lo haces.

Lo que forma parte de su trabajo en este momento (si cree que es útil escribir pruebas unitarias) va a su gerente y discuta esa discusión. Lo que no es su responsabilidad es convencer a su gerente. Le pagan bien para hacer su trabajo, y es su trabajo asegurarse de que todos usen los mejores métodos para desarrollar software.