Réponse.

Une version et une intégration appropriées des tests automatisés sont essentielles pour garantir que les vérifications correspondent à l'état actuel du projet.

Historique de la question

Les tests automatisés étaient souvent gérés séparément du projet principal, ce qui entraînait des incompatibilités et des problèmes de maintenance. Le développement de plusieurs branches, les mises à jour fréquentes des logiciels et des tests ont engendré la nécessité d'un système de contrôle de version commun.

Problème

Sans versionnage et intégration cohérente, il y a :

Exécution de tests non à jour sur un logiciel modifié
"Casser" les tests lors du déploiement de nouvelles fonctionnalités ne tenant pas compte des modifications apportées aux tests
Échecs dans CI/CD

Solution

Approche moderne :

Les tests sont stockés dans un système de contrôle de version commun (le plus souvent git)
Association de la branche de test avec la branche de développement logiciel : dans la branche feature, les tests et le code sont développés ensemble
Vérifications/assemblages automatiques sont effectués via des pull requests
Révision et approbation des modifications des tests et du code

# Approche générale :
git checkout -b feature/new_login
# La fonctionnalité et les tests sont développés et testés ensemble
# Après révision, ils sont fusionnés ensemble dans la branche principale

Caractéristiques clés :

Cohérence des changements de code et de tests (pas de désynchronisation)
Rétrogradation et comparaison des versions faciles (via l'historique git)
Possibilité de travail d'équipe et de révision de code des tests automatisés

Questions pièges.

Peut-on stocker les tests dans un dépôt séparé (du code du projet) ?

Oui, mais il devient alors plus difficile de maintenir l'actualité des tests, un synchronisation manuelle est requise, et il y a un risque d'"oublier" de mettre à jour quelque chose lors d'un déploiement ou d'un correctif.

Les tests doivent-ils couvrir immédiatement toute la nouvelle fonctionnalité lors de la création d'une PR ?

Idéalement — oui, en pratique, ils couvrent souvent les principaux scénarios dans le premier PR, et les cas complexes sont traités dans des tâches séparées. L'essentiel est que la fonctionnalité critique soit couverte immédiatement.

Peut-on annuler uniquement les changements de tests sans revenir au code ?

Si les tests et le code sont dans une seule branche — oui, il est possible d'annuler les révisions. Mais il est préférable d'éviter d'"annuler" les tests sans le code : cela dégrade la qualité de la vérification.

Erreurs typiques et anti-modèles

Stocker les tests hors de git, sur des systèmes de fichiers
Gérer les tests dans un dépôt séparé sans lien clair avec le projet
Fusionner des tests de l'extérieur (post factum), plutôt que simultanément avec le code

Exemple de la vie

Cas négatif

Projet avec un dépôt séparé pour les tests automatisés. Après le déploiement, les programmeurs ont "oublié" de mettre à jour les tests — les tests échouaient, des vérifications non à jour étaient effectuées, et des bogues étaient attrapés en production.

Avantages :

Les programmeurs pouvaient travailler indépendamment de l'équipe QA

Inconvénients :

Perte de temps en synchronisation, présence de tests "obsolètes"

Cas positif

Les tests et le code du projet sont gérés dans une même branche git : à chaque nouvelle pull request, les tests automatisés sont systématiquement mis à jour pour le code ajouté. Tous les changements passent par une révision de code et des vérifications automatiques.