Acabo de cambiar la configuración de la bifurcación en mi repositorio de GitHub, de modo que mi [próxima] bifurcación requiere una compilación de CI pasante a través de una solicitud de extracción.
Siguió una discusión con varios miembros del equipo, sobre la falla de las pruebas.
Por el bien del contexto ...
El repositorio tiene una rama [maestra] en la que solo se introduce PR cuando hay una versión, por lo que [maestra] contiene el código de la última versión, independientemente de si es mayor, menor, revisión, beta, alfa / compilación previa al lanzamiento.
La rama [siguiente] es la "predeterminada", donde tenemos la intención de mantener el código "listo para liberar"; técnicamente, esa rama podría ser introducida en [maestro] en cualquier momento y liberada.
Los tenedores individuales tienen sus propias ramas de desarrollo, y los contribuyentes de relaciones públicas a [siguiente].
Cuando reviso un RP no trivial, fusionaré la rama de desarrollo del contribuyente en mi rama de "revisión", y si veo cosas que puedo solucionar rápidamente, comprometeré / empujaré cambios y nuevas pruebas (a veces fallidas), y PR volver a la rama de desarrollo del contribuyente; cuando combinen mis cambios, hagan pasar las nuevas pruebas fallidas y luego presionen, su PR se sincronizará, y luego fusionaré el PR en [siguiente].
Pero esta pregunta no se trata de pasar las pruebas, se trata de las que fallaron .
Las pruebas fallidas documentan lo que necesita ser reparado.
Los errores conocidos deben tener pruebas escritas, para que sepamos lo que no funciona.
Técnicamente, la lista de problemas de GitHub (filtrada por errores y / o etiquetas críticas ) también lo hace. ¿Es una buena práctica tener también un montón de pruebas fallidas para documentar errores?
Una acumulación fallar en [siguiente] significaría que no estamos listos para liberar ... pero entonces "ser comunicado listo" es un poco como "estar listo" para tener hijos - nunca se es bastante listo para esto, y algo, en algún lugar (de importancia variable) inevitablemente saldrá mal con el lanzamiento.
Así que solo estamos presionando las pruebas de aprobación para [siguiente]. ¿Dónde empujar las pruebas fallidas entonces? Quiero decir, ¿fuera del proceso de revisión / relaciones públicas?
Por ejemplo, un usuario informa un nuevo error en la lista de problemas, y me gustaría escribir un conjunto de pruebas fallidas para ello, a fin de especificar qué se debe hacer y dónde, lo que hace que sea más fácil para los nuevos contribuyentes recoger y eventualmente PR una solución.
¿Dónde debería estar empujando estas pruebas fallidas? ¿O es incluso una buena idea llevar las pruebas reprobadas a cualquier lugar?