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

15

Estoy trabajando en un equipo que escribe principalmente sitios PHP pequeños. Actualmente no tenemos el hábito de escribir test de unidad. Las pruebas se realizan utilizando el sitio como usuario por parte de nuestro PM, que no sabe cómo codificar, y UAT por parte del cliente. Sin embargo, a medida que los proyectos que tomamos se hacen más grandes, comienza a tener más errores creados debido al cambio de código y es posible que no se descubran ya que la prueba ya se realizó en esa parte.

Por ejemplo, después de hacer la parte A y la amp; B, el error se encuentra en la parte C. Después de la depuración de la parte C, causa un error en la parte A, pero no se observa como se han realizado pruebas en esa parte. A medida que el proyecto crece, puede que no sea posible probar todo el sitio después de cada cambio. Así que creo que es hora de introducir la prueba de unidad.

El problema es que el programa está apretado y no tengo mucho tiempo para hacer este trabajo adicional, por lo que no es posible escribir un caso de prueba en cada caso, por no mencionar el enfoque de desarrollo basado en pruebas. Además, debo demostrar que escribir un caso de prueba no es una pérdida de tiempo para que mis compañeros de equipo empiecen a escribir un caso de prueba y, lo más importante, mi jefe nos dará más tiempo para hacerlo. Estoy planeando comenzar a escribir la prueba de unidad en la función principal y si comienza a detectar un error que anteriormente no se ha notado, pero no tengo idea de qué función elegir. La mayoría de los guías nos dicen que escribamos un caso de prueba para cada caso que no es posible para nuestra situación. ¿Hay algún consejo sobre qué hacer con la prueba unitaria para comenzar?

    
pregunta cytsunny 31.10.2016 - 03:30
fuente

3 respuestas

15

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.

    
respondido por el candied_orange 01.11.2016 - 07:49
fuente
3

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.

    
respondido por el sharpweed 06.11.2016 - 12:14
fuente
2

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.

    
respondido por el gnasher729 31.10.2016 - 10:10
fuente

Lea otras preguntas en las etiquetas