¿Debe realizarse una revisión del código antes o después de las pruebas unitarias?

Estoy debatiendo con mi colega cuándo realizar la revisión del código, antes o después de las pruebas unitarias. cual es la mejor practica?

Algunos factores que debemos tener en cuenta (puede haber más):

• Tamaño del cambio de código: un gran cambio significa que se producirán más cambios a partir de la revisión del código. Si estos cambios son mayores que, si UT fue antes de la revisión del código, deberá repetir la mayoría de sus UT nuevamente.
• Tiempo requerido para realizar la prueba unitaria
• ¿Es nueva funcionalidad o una corrección de errores?

Siempre debe realizar una prueba unitaria antes de hacer la revisión del código y aquí le explicamos por qué

1. Si su código se rompe de una manera que sería atrapada por las pruebas unitarias, perderá el tiempo del otro desarrollador al involucrarlos en el ciclo rojo / verde / refactorizador.
2. Las pruebas muestran a otros desarrolladores el uso previsto del código que facilita su revisión.
3. Las pruebas deben revisarse junto con el código que se prueba en caso de que falten casos de prueba o sus pruebas no funcionen correctamente.
4. Las pruebas y la revisión del código tienden a detectar diferentes problemas con solo una pequeña superposición en los problemas encontrados. Las pruebas unitarias no se molestan por tener que volver a probar el código cuando el revisor encuentra problemas, los desarrolladores se molestan y probablemente no lo hagan tan bien la segunda vez.

Probablemente haya otras razones, pero esas son las que personalmente he visto y experimentado al implementar prácticas de revisión de código en 3 equipos / compañías diferentes.

Editar Por supuesto, lo anterior es para los momentos en que la revisión de código es un paso en el proceso de desarrollo de software (ya sea en cascada o ágil). Si está trabajando en una sección de código particularmente grande o difícil, siéntase libre de tener otro par de ojos sobre ella en cualquier momento.

Las revisiones de código son para cuando el código está "hecho".

En mi organización, nuestra definición de "hecho" incluye pruebas unitarias (ya que apuntamos a TDD), por lo que las revisiones de código son de código completo, y el código completo incluye pruebas.

Además, las pruebas necesitan revisión y refactorización, por lo que tiene sentido que sean parte de la revisión del código.

Las pruebas deben considerarse parte del código para revisar. Por lo tanto, tiene sentido revisar después de realizar las pruebas.

Asegúrese de que las pruebas también se revisen. Esto es crítico para aquellos que son nuevos en las pruebas unitarias.

Asegúrese de que su equipo comprenda la inyección de dependencia, los marcos de aislamiento, los simulacros frente a los trozos, las costuras, la interacción frente a las pruebas basadas en el estado y las pruebas de integración frente a las unidades.

No necesita implementar los temas antes mencionados, pero debe comprenderlos.

Bien,

Esto depende de lo que quiere decir con "Prueba de Unidad" ...

Si se trata de una prueba de unidad de estilo TDD, no tiene sentido porque escribe una prueba mientras escribe su código. No hay ningún caso posterior. En este caso, mejora la calidad del código continuamente: Refactorización ...

Y

Si se tratara de una "prueba unitaria" clásica [lo que significa que no lo sé, pero me refiero a una prueba después de que usted escribe los códigos y lo hacen generalmente otras personas], entonces el criterio principal es lo que espera de la revisión de código y la naturaleza de las pruebas unitarias: si desea una revisión rápida, hacer comentarios y tomar medidas y no tiene una prueba unitaria automatizada, tendrá que esperar la prueba unitaria. Si desea identificar problemas maduros con la revisión de código y aplicar la solución de forma incremental para las próximas iteraciones, puede hacerlo antes de la prueba unitaria ...

Pero, después de todo, personalmente, para la revisión de código, la prueba de unidad posterior o posterior no es un criterio real para mí ...

¿Por qué hacemos codereview? Para la calidad del código ... En lugar de una puerta de "control de calidad", inyecte calidad en su entorno de proceso de desarrollo de software ...

Tiendo a decir, seamos "ágiles" ... no esperes a que termine el código para hacer una revisión rápida e informal del código: hay desarrolladores con los que y sujetos con los que puedes esperar todo el tiempo código + fase de prueba para terminar ... pero

cuando se trata de temas realmente nuevos (función completamente nueva, casi investigación, algo totalmente nuevo para el equipo), revisión de código temprana, no pierda tiempo: haga que un compañero de trabajo eche un vistazo de vez en cuando: el aislamiento es un factor importante de fracaso en este caso.

si el desarrollador también es nuevo en el equipo, revise el código temprano y tal vez con frecuencia .

y, por cierto, las pruebas unitarias también necesitan revisión de código.