unit testing - test - ¿Qué debe hacerse primero: Revisiones de código o Pruebas unitarias?
tdd ejemplo (22)
Bueno, si tomas el Test Driven Development (TDD, bueno les gusta llamarlo Comportamiento entonces BDD ahora) entonces escribirías las pruebas unitarias antes del código.
Sin embargo, en esta introducción, como el código ya está escrito, sugeriría que un desarrollador junior primero inspeccionara el código, ya que el significado de la clase bajo prueba podría cambiar completamente invalidando los casos de prueba anteriores. Si hay una menor inversión emocional en el código que se revisa (creado por el mayor tiempo dedicado a realizar las pruebas unitarias), el autor será menos propenso a discutir sobre los cambios y podría aprender mucho más del mentor de codificación.
Sin embargo, no defiendo esa opinión con demasiada fuerza, y si el desarrollador no tiene nada más que hacer mientras espera la revisión del código, o tiene suficiente experiencia, entonces, ciertamente, puede comenzar con las pruebas unitarias.
Si un desarrollador implementa código para algún módulo y desea que lo revisen. ¿Cuál debería ser el orden?
* La primera unidad prueba el módulo después de diseñar los casos de prueba para el módulo, depurando y corrigiendo los errores y luego da el código modificado para la revisión del código de los pares
( Ventajas : el código que se revisará es "limpio" en buena medida. Reduce algunos comentarios de revisión evitables y la reelaboración. Desventajas : el desarrollador puede pasar mucho tiempo depurando / corrigiendo un error que podría haberse apuntado / anticipado en revisiones de códigos de pares)
O
* Primero revise el código con sus compañeros y luego haga una prueba unitaria.
¿Cuáles son tus pensamientos / experiencias sobre esto?
Creo que este enfoque para las pruebas unitarias, la revisión del código debe ser independiente del lenguaje de programación, pero sería interesante saber lo contrario (si corresponde) con ejemplos específicos.
-ANUNCIO
Cuando se informa un error y se confirman / reproducen otros, lo primero que se debe hacer es escribir un caso de prueba reducido. El código de corrección de errores escrito por cualquier desarrollador debe ejecutarse contra el caso de prueba reducido. Solo cuando el código de corrección pase el caso de prueba se debe mover a revisión. La revisión es un proceso que no puede automatizarse. Una tarea de los revisores es no ver si el código funciona, si se envía para su revisión lo más probable es que lo haga. Su tarea es dar una "mirada" para ver si podría haber algún error en el código, o si el desarrollador no siguió algunos estándares de codificación, o no usó la función correcta y usó la biblioteca incorrecta y un montón de otros cosas que solo un ser humano podrá contar.
Lo que puede hacer es asignarle a alguien más experiencia para escribir el caso de prueba reducida. Y muchos otros desarrolladores analizarán este caso de prueba de todas formas, así que esto es como una especie de revisión informal. Una vez que no se transmite la voz sobre el caso de prueba, simplemente consíguelo.
¡En serio, no quiere pasar por el problema de escribir código y hacerlo revisar solo para descubrir que no pasa ningún caso de prueba!
El problema de escribir código de prueba más tarde es que a veces pueden suceder dos cosas: 1. El desarrollador podría escribir el código de prueba con su código en mente. 2. Al escribir el código de prueba, el desarrollador puede descubrir que, ¡eh !, mi código no pasaría esto e irá y arreglará su código nuevamente y escribirá un código de prueba explícitamente codificado para pasar el código que acaba de escribir.
Siempre es una buena idea escribir el caso de prueba primero.
Dado que siempre debe comenzar su prueba de unidad antes de comenzar su clase / método y escribir los dos en tándem, la prueba de unidad debe ser tan completa como el código que se está revisando.
Las revisiones de diseño, a veces con pseudocódigo o código POC, ocurren a menudo antes que nada de esto.
Hay varias formas de hacer revisiones de código, por lo que la respuesta depende de lo que signifique. Las revisiones de código en su forma básica es dejar que otras personas echen un vistazo a la pieza específica de código que haya escrito.
Cuando las personas hablan de revisiones de códigos, inmediatamente piensan que están en forma de reuniones en las que un grupo de desarrolladores se sienta y repasa el código que han hecho. No tiene por qué ser así . Si los desarrolladores lo encuentran útil, apéguese a él. Pero si se considera que es un desperdicio, entonces necesita encontrar algunas alternativas a este tipo de reuniones.
Una reunión de revisión de código se puede escalar de muchas maneras, es decir, puede tratarse brevemente con solo dos personas (el tipo que escribe el código y el tipo que lee el código) o una reunión larga donde varias personas recorren el código.
Antes versus después
Si decide escribir pruebas unitarias después , la revisión del código se vuelve más sobre verificar si el código funciona . Lo que quiero decir con eso es que los revisores deben pasar por todas las condiciones en su cabeza, por ejemplo, asegurarse de que el código compilado pueda captar argumentos que no fueron intencionados.
Si escribe pruebas unitarias antes de una revisión del código, las revisiones del código se vuelven más sobre verificar que el código haga lo correcto y puede estar seguro de que, independientemente de la especificación del requisito, una prueba específica añadida también funciona y prueba lo que se pretende. Esto también ayuda a la trazabilidad entre requisitos, códigos y pruebas.
¿Por qué no ambos al mismo tiempo?
... o podría simplemente hacer ambas cosas al mismo tiempo usando Pair Programming con el driver y mapreder metafor. El controlador escribe el código, mientras que el lector de mapas es el otro conjunto de ojos, asegurándose de que el controlador escriba un buen código y, por lo general, también escribe las pruebas de la unidad. Esto podría considerarse una prueba unitaria y una revisión de código en iteraciones realmente pequeñas, de minutos largos.
En mi experiencia, primero iba con pruebas usando Test Driven Development y permitía que alguien revisara mi código para ver que hice lo correcto. Eso funcionará si todos los desarrolladores de un proyecto conocen una buena arquitectura de código, pero ese es un tema completamente diferente.
Imho, no hay una regla de oro que deba hacerse primero. Las revisiones tempranas del código son agradables, especialmente para un desarrollador menos experimentado, pero en realidad si tiene que esperar a que alguien revise el código, siga adelante y realice las pruebas unitarias primero.
Intentamos hacer lo siguiente:
- La persona A escribe un código (con pruebas de curso)
- La persona B escribe algunas pruebas unitarias contra el código
- La persona A + B hace una revisión del código y las pruebas
La revisión del código debe hacerse antes de cualquier compromiso con el control de origen. Cualquier corrección de errores también se revisa. De esta forma, se revisa cualquier código en el control de origen.
Como parte de la revisión del código, le solicito al desarrollador que también demuestre la funcionalidad para que se pueda verificar que funcione.
Las pruebas unitarias se escriben primero, antes de que haya algún código para revisar ...
Primero, la prueba de unidad tiene la ventaja de que, durante la revisión del código, puede comenzar leyendo las pruebas, que efectivamente comprenden una especificación para la nueva funcionalidad. Cuando veo una revisión de código que contiene un montón de cambios de código sin pruebas, es como, ok, ¿qué se supone que debe hacer o corregir? Cuando las pruebas están ahí, es fácil: las pruebas establecen el escenario para el objetivo del resto de la revisión del código. Además, el revisor tiene más confianza en que el código realmente funciona (en lugar de simplemente codificar algo y no lo ha probado minuciosamente y quiere pasar el tiempo encontrando errores que podrían haber encontrado al escribir pruebas).
Además de todas las ventajas que confiere el desarrollo de prueba primero (aparte de las revisiones).
Recomiendo escribir las pruebas unitarias antes de la revisión. Por lo tanto, tendrá una red de seguridad para modificar el código en función de los comentarios de revisión.
(Por otro lado, si el código no fue probado por la unidad antes de la revisión, nunca sabrá si esos cambios rompen cualquier cosa: 0)
Revisión de código pero con el objetivo explícito de identificar casos de prueba que se registrarán cuando realice la revisión. Esto enfoca al revisor en la búsqueda de anomalías que puedan ser probadas, por ejemplo: comprobación de entradas, casos extremos, etc.
En la mayoría de los lugares, esperaría que la cobertura de las revisiones de códigos sea mucho menor que la cantidad de código que cubren las pruebas unitarias. Se debe programar una revisión de seguimiento para el mismo código con las pruebas. Las lecciones aprendidas en la creación y el perfeccionamiento de estas pruebas se convierten en pautas para que las personas puedan autorevisarse y tener en cuenta al escribir nuevas pruebas.
Si el tiempo fue corto, ¿qué preferirías haber hecho?
Como se dijo anteriormente, una revisión del código es agradable, pero las pruebas unitarias son vitales.
Las pruebas unitarias encuentran más errores que la revisión del código, en mi experiencia. Por lo tanto, primero haz pruebas unitarias.
Además, cuando realizo las revisiones de los códigos, necesito saber que el código funciona, de modo que pueda mirar de forma rítmica la estructura del código, cómo se construye el SQL, si el código cumple con las necesidades de la funcionalidad, etc. Es mucho es más difícil revisar el código que NO SÉ funciona.
Desde el punto de vista de la logística, debe programar que alguien revise el código, pero no es necesario para la prueba unitaria.
Pruebas unitarias siempre antes de revisiones del código.
Si la revisión del código ocurre antes de que se escriban las pruebas unitarias, ¿no significa eso que nadie revisa las pruebas unitarias? ¿O anticiparía que se haga en una segunda revisión?
Como han dicho otros, escribir las pruebas antes o al mismo tiempo que el código es generalmente una mejor idea. Tengo que admitir que ha habido momentos en los que ha sido "obvio" que hay un error, y lo he reparado antes de escribir la prueba unitaria para demostrar la rotura ... He encontrado que en tales casos, si estoy disciplinado y comentar la solución, escribir la prueba y ver que se vuelva roja antes de solucionarlo, mi solución "adivinada" a menudo no es la correcta de todos modos.
Soy partidario de que la revisión de código sea el último paso después de que el desarrollador haya realizado todas sus pruebas (pruebas unitarias, pruebas de integración, paso por el código, haga que el código advierta de forma gratuita y cualquier prueba de caja "negra" sea apropiada). Ahora puedo pedir comentarios sobre el código (hey, ¿cómo se ve esto en una API) mucho antes si tengo preguntas sobre algo? Mi experiencia es que las revisiones de código encuentran errores pero no muchos de los lógicos superduros a menos que pases mucho tiempo revisando el código. El revisor podría hacer un par de preguntas difíciles (¿este subproceso es seguro? ¿Qué sucede si x falla?) Pero es realmente difícil descifrar todos los casos en código en los que no ha estado pensando durante un tiempo. Todavía es muy útil para ayudar a realizar un seguimiento de lo que está sucediendo en el resto del proyecto.
en mi compañía seguimos estrictamente para hacer la prueba unitaria primero. La razón principal para hacerlo es que la funcionalidad para la cual se realiza el cambio de código está garantizada en la prueba unitaria. Si esto no se hace completamente, no tiene sentido hacer una revisión del código.
Escribí un blog sobre este gran artículo de IEEE de Robert Glass titulado Datos Fundamentales Frecuentemente Olvidados sobre Ingeniería de Software que es relevante para su pregunta.
- Realmente necesita tanto revisiones por pares como pruebas de caja blanca.
- Si tuviera que elegir entre revisiones de código y pruebas de unidad, no elegiría ninguna de las dos . La actividad de eliminación de defectos más eficaz es la revisión del diseño .
Dado que la "revisión del código" aquí significa la revisión por parte de alguien que no sea el autor del código, entonces tendré que decir la revisión del código en segundo lugar, y por lo tanto las pruebas unitarias primero. Pero no por ninguno de los motivos dados hasta ahora.
La mayor parte del costo del software está en mantenimiento: reparaciones y extensiones. La mayor causa de defectos en esa fase son los cambios incorrectos porque el desarrollador que lo mantiene no entiende completamente el código que está cambiando. Por lo tanto, el enfoque más rentable de la revisión del código es la legibilidad. Problemas de estilo no triviales, pero legibilidad = comprensibilidad + nivel correcto de detalle en cada ámbito.
El objetivo de un autor del código, entonces, es producir un código legible, sabiendo que un revisor del código desafiará al código por no ser lo suficientemente legible. El autor del código primero debe hacer lo que pueda para que el código sea legible para él primero. Escribir pruebas unitarias es una gran manera de hacerlo, porque obliga al autor del código a volver a leer su propio código y asegurarse de que sea comprensible para un público simple e implacable: la prueba unitaria. En realidad, pasar las pruebas unitarias es una ventaja: son las pruebas unitarias fallidas las que tienen algún valor porque hacen que el autor del código vuelva a leer el código y lo solucione. Dicho de otra manera, escribir pruebas unitarias es lo más cerca que un autor de códigos puede llegar a "salir de sí mismo" y revisar su propio código objetivamente.
Después de que el código sea lo suficientemente legible para que el autor del código escriba las pruebas unitarias, un beneficio adicional proviene de obtener otro objetivo, el revisor del código, para leerlo.
Por lo tanto,
- Escribir pruebas unitarias
- Obtener revisión de código
(Por cierto, esto es todo si está escribiendo pruebas unitarias. Si tiene que elegir, mantenga la revisión del código como se describe, porque el código ilegible es mucho más propenso a errores que el código legible que no se ha probado en la unidad o solo función o nivel de método. Las pruebas más importantes, eso debe suceder, es a nivel de componente y sistema. Esto se debe a que la mayoría de las fallas ocurren cuando interactúan múltiples componentes: las pruebas unitarias no encontrarán esos problemas.
Primero debería revisar el código porque obliga a las personas a tomarse el tiempo de leer el código. Las pruebas unitarias se ejecutan automáticamente y algunas personas caerán en la trampa de pensar que "pasa la prueba para que funcione". Las pruebas pueden no estar probando lo correcto y si cometieron un error, es posible que no hayan entendido completamente su error para evitar que vuelva a suceder.
Mi respuesta: revisión del código.
Las pruebas unitarias pueden reescribirse debido al diseño subyacente o al cambio de funcionalidad como resultado de la revisión del código.
No pierdas el tiempo de los revisores. Las pruebas unitarias y las herramientas de revisión automatizada, incluido el análisis estático y la cobertura de prueba, son una forma económica de encontrar problemas, tal como lo hace el compilador.
En primer lugar, debe definirse exactamente qué se hace durante la prueba unitaria y qué se hace durante una revisión.
(Supongo que hay requisitos o algún tipo de descripción de la tarea antes de que el codificador haya comenzado a codificar)
Las pruebas unitarias, escritas por la misma persona que escribió el código, son verificación .
Las pruebas unitarias, escritas por otro codificador, son verificación y validación (parcial) .
La revisión de código puede hacer una combinación de verificación y validación (parcial) .
la verificación es "el código lo está haciendo bien".
la validación es "el código está haciendo lo correcto".
La validación completa se realiza automáticamente en las pruebas de integración, ya que otras partes del código van a usar su pieza, y cualquier error en su interpretación del requisito, o cualquier error en el requisito en sí mismo aparecerá. ¿Tu unidad está haciendo lo correcto?
Verificación que puede hacer de inmediato una vez que haya codificado. Puedes hacer esto usando pruebas unitarias. (Sin embargo, hay límites a lo que las pruebas unitarias pueden verificar, una revisión puede verificar el código de una manera mucho más completa, pero es engorroso)
Si realiza un conjunto completo de pruebas unitarias antes de revisar, es posible que haya terminado haciendo todo el trabajo en vano, porque el revisor le señalará que ha interpretado el requisito incorrectamente al codificar. O que el requisito en sí es incorrecto o incompleto, etc. Eso significa que no solo necesita volver a escribir el código, sino también las pruebas de la unidad.
Si tiene suerte, el revisor solo detectará alguna "posible división por cero" o "no verificará el desbordamiento", etc., y puede agregar pruebas unitarias para estos casos límites a su suite de pruebas.
Sin embargo, si no hay requisitos en primer lugar (muy común ...), entonces sus pruebas funcionan como casos de uso. El revisor puede ver sus intenciones al revisar las pruebas (los casos de uso).
De hecho, si no hay requisitos, es mejor que los escriba usted mismo, ya sea en forma de requisito o como casos de uso. Esto es lo que haría antes de codificarme. Y haga que el revisor revise los requisitos primero, antes de que empiece a codificar. De esta forma, se realiza una validación parcial antes de la implementación y las pruebas, y se ahorrará MUCHO tiempo de tipeo.
Una vez dicho esto, averiguar el requisito correcto en primer lugar generalmente requiere una codificación real ... todo se reduce al proceso en cascada (primero en el diseño) frente al proceso de prototipado rápido (primero en el código). Adaptar el proceso a sus circunstancias es la clave. Para hacer eso, necesitas entender tus circunstancias en lugar de usar ciegamente las "mejores prácticas". Por lo tanto, no recomiendo hacer la revisión primero o las pruebas primero, recomiendo averiguar qué es lo que se adapta a sus circunstancias.
Aquí tomé un poco de tema, pero no puedo elegir un fragmento de proceso y proponer algún tipo de recomendación general. La imagen completa es necesaria.
¡aclamaciones!
/Por
Las revisiones de código deben hacerse primero .
Las revisiones y reuniones nos permiten evaluar documentos, planos, códigos, requisitos y especificaciones . Una vez que conocemos los requisitos y las especificaciones, podemos comenzar a probarlos como en Pruebas unitarias. No se usan pruebas sin tener ningún conocimiento general sobre el código, los requisitos y las especificaciones. Por lo tanto , las Revisiones de código se deben hacer primero para familiarizarse con el código y sus requisitos.