Lorsqu'une intégration continue exécute les tests à chaque validation, une meilleure pratique courante consiste à faire passer tous les tests à tout moment (c'est-à-dire "ne pas interrompre la construction").
Je trouve quelques problèmes avec ça:
Par exemple, on ne peut pas aider un projet open source en créant des tests correspondant aux tickets. Je sais que si je propose une Pull Request à un projet open source contenant un test ayant échoué, la build sera marquée comme ayant échoué et le projet ne voudra pas que cela soit fusionné dans son référentiel car cela "casserait la build".
Et je ne pense pas que ce soit une mauvaise chose d'avoir des tests qui échouent dans votre dépôt , c'est comme avoir des problèmes ouverts dans votre tracker. Ce ne sont que des choses qui attendent d'être corrigées.
Il en va de même dans une entreprise. Si vous travaillez avec TDD, vous ne pouvez pas écrire de tests, valider puis écrire le code logique qui remplit le test. Cela signifie que si j'ai écrit 4 à 5 tests sur mon ordinateur portable, je ne peux pas les valider avant de partir en vacances. Personne ne peut reprendre mon travail. Je ne peux même pas les "partager" avec un collègue sauf en les envoyant par mail par exemple. Cela empêche également de travailler avec une personne écrivant les tests, l'autre écrivant le modèle.
Tout cela pour dire: suis-je en train de mal utiliser / mal comprendre le processus de construction / l'intégration continue? Il me semble que «passer» / «ne pas passer» est un indicateur trop étroit.
Existe-t-il un moyen de rendre l'intégration continue et compatible TDD?
Peut-être existe-t-il une solution / pratique standard pour distinguer les "nouveaux tests" (qui peuvent échouer) et les "tests de régression" (qui ne devraient pas échouer car ils fonctionnaient auparavant)?