Estoy revisando un Bitcoin Core PR abierto. ¿Debo ejecutar las pruebas o puedo confiar en la salida de CI (integración continua) para detectar fallas en las pruebas?
Si debo confirmar un compromiso, ¿debería intentar detectar pruebas inestables, ejecutar pruebas en hardware diferente, probar casos de prueba adicionales manualmente?
Esta pregunta fue hecha por robot-dreams en IRC.
Las pautas de contribución de Bitcoin Core recomiendan que publique Concept ACK, Approach ACK:
Una revisión comienza con ACK BRANCH_COMMIT, donde BRANCH_COMMIT es la parte superior de la rama PR, seguida de una descripción de cómo el revisor realizó la revisión.
Como usted sugiere, "realicé las pruebas en hardware típico" generalmente no es particularmente útil ya que Bitcoin Core tiene herramientas de CI que mejoran sólidamente, pero hay excepciones, por ejemplo, un cambio de GUI no está cubierto por las pruebas y sería valioso ejecutar pruebas para ciertas EII , cambios de validación, cambios no triviales también.
Dependiendo de la naturaleza del PR, es posible que desee realizar un flujo de trabajo menos trivial, como enviar y recibir transacciones.
Para obtener una seguridad adicional de que se siente cómodo con el cambio de código, puede agregar impresiones de depuración, afirmaciones, registro personalizado y controles de cordura. Puede cambiar el parche o usar herramientas de depuración como gdb y lldb.
Puede romper muchas cosas sin que el CI o el conjunto de pruebas lo detecten. Las pruebas manuales pueden detectar cosas que podrían pasarse por alto en la revisión del código. Es posible que vea advertencias o errores al depurar los PR de compilación que de otro modo no vería, ya sea porque está oculto en uno de los registros de trabajo de CI o porque su compilador, configuración o sistema es diferente.
Si el RP está implementando un BIP particular, puede encontrar una regla particular del BIP en el código, mutar (romper) el código y verificar que las pruebas fallan como resultado.
Otra cosa a considerar es si las pruebas adicionales agregadas en el PR son suficientes.
[editar: un ejemplo de algo que puede probar que el CI no probará es cambiar una línea de código en el PR, reconstruir (es decir, ejecutar de nuevo) makey ejecutar la prueba (o varias pruebas) que espera que falle como un resultado. Jon Atack sugirió que esta es una buena manera de revisar PR #19951 que al momento de escribir (septiembre de 2020) está abierto y en busca de revisión.]
Esta respuesta se recopiló a partir de comentarios de sipa, jonatack, hebasto, jnewbery, robot-dreams, instagibbs en IRC.