Quand un test commence à échouer sur la ligne de production, la première question est toujours : « Qu'est-ce qui a changé ? » Si vos scripts de test ne sont pas versionnés, vous ne pouvez pas y répondre. Git vous donne un historique complet de chaque modification de chaque test. TofuPilot lie chaque exécution de test à la version exacte du code qui l'a produite.
Ce guide couvre le flux de travail Git pour les projets de test, l'intégration des hash de commit dans les métadonnées de test, et un .gitignore pratique pour les dépôts de tests matériels.
Pourquoi le contrôle de version est important pour les tests matériels
Les scripts de test matériel ne sont pas du code jetable. Ils font partie de votre système qualité. Les régulateurs, les auditeurs et votre futur vous-même ont besoin de savoir :
- Quelle version du script de test a produit un résultat donné
- Qui a changé une limite de mesure, et quand
- Si le test exécuté en DVT est le même que celui exécuté en PVT
Sans Git, vous obtenez des dossiers nommés test_v2_final_FINAL_john.py. Avec Git, vous obtenez une piste d'audit propre.
Flux de travail Git pour les scripts de test
Une stratégie de branches simple fonctionne bien pour les projets de test. Vous n'avez pas besoin de GitFlow. Vous avez besoin de quelque chose que votre équipe utilisera réellement.
main ──●──●──●──●──●──●── (tests prêts pour la production) \ /feature/add- ──●──●──●──● (nouveau test ou modification)thermal-testmain est toujours déployable sur les stations de production. Chaque commit sur main a été revu et testé.
Les branches de fonctionnalité sont l'endroit où vous développez de nouveaux tests ou modifiez les existants. Nommez-les de manière descriptive : feature/add-thermal-cycling, fix/dmm-timeout-handling, update/voltage-limits-rev-c.
Flux de travail de base :
# Démarrer une nouvelle modification de testgit checkout -b feature/add-current-measurement# Faites vos modifications, testez localementgit add tests/power_rail_fct.pygit commit -m "Add idle current measurement to power rail FCT"# Poussez et créez une pull request pour revuegit push -u origin feature/add-current-measurement# Après revue, fusionnez dans maingit checkout maingit pullgit merge feature/add-current-measurementgit pushTaguez les releases quand vous déployez sur les stations de production :
# Taguer une release avant le déploiement en productiongit tag -a v1.2.0 -m "Add thermal cycling test, update voltage limits for Rev C"git push origin v1.2.0Intégrer le hash de commit Git dans les métadonnées de test
Liez chaque exécution de test au code exact qui l'a produite. C'est le lien de traçabilité clé entre vos résultats de test et votre code de test.
import subprocessdef get_git_info() -> dict: """Récupère le hash de commit et le tag Git courants.""" info = {} try: info["commit"] = subprocess.check_output( ["git", "rev-parse", "HEAD"], stderr=subprocess.DEVNULL, ).decode().strip() info["commit_short"] = subprocess.check_output( ["git", "rev-parse", "--short", "HEAD"], stderr=subprocess.DEVNULL, ).decode().strip() # Vérifier s'il y a des modifications non commitées status = subprocess.check_output( ["git", "status", "--porcelain"], stderr=subprocess.DEVNULL, ).decode().strip() info["dirty"] = len(status) > 0 # Récupérer le dernier tag si disponible try: info["tag"] = subprocess.check_output( ["git", "describe", "--tags", "--abbrev=0"], stderr=subprocess.DEVNULL, ).decode().strip() except subprocess.CalledProcessError: info["tag"] = None except subprocess.CalledProcessError: info["commit"] = "unknown" info["commit_short"] = "unknown" info["dirty"] = True info["tag"] = None return infoTaguer les exécutions de test avec la version du code dans TofuPilot
Passez les informations Git en métadonnées quand vous créez une exécution de test. Chaque exécution dans TofuPilot indiquera quel commit l'a produite.
import openhtf as htffrom openhtf.util import unitsfrom tofupilot.openhtf import TofuPilotfrom git_version import get_git_infogit_info = get_git_info()# Avertir si l'exécution se fait avec des modifications non commitées en productionif git_info["dirty"]: print("ATTENTION : Exécution de tests avec des modifications non commitées")@htf.measures( htf.Measurement("voltage_3v3").in_range(3.2, 3.4).with_units(units.VOLT),)def test_power_rail(test): test.measurements.voltage_3v3 = 3.29def main(): test = htf.Test(test_power_rail) # Passer les infos git en métadonnées d'exécution with TofuPilot( test, script_version=git_info.get("tag") or git_info["commit_short"], ): test.execute(test_start=lambda: "DUT-001")if __name__ == "__main__": main()Maintenant, quand vous consultez une exécution de test dans TofuPilot, vous pouvez voir quelle version du code l'a produite. Si un test commence à échouer après un déploiement, comparez le script_version des exécutions réussies avec celles qui échouent pour trouver le changement.
Modèle .gitignore pour les projets de test
Les dépôts de tests matériels ont des fichiers spécifiques que vous ne voulez pas suivre. Voici un point de départ pratique.
# Python__pycache__/*.py[cod]*.so*.egg-info/dist/build/venv/.venv/# Environnement et secrets.env.env.*!.env.example# IDE.vscode/.idea/*.swp*.swo# Artefacts de test (logs, rapports, captures)logs/test_output/*.log*.csvcaptures/screenshots/# Données de calibration des instruments (spécifiques à la station)cal_data/fixture_cal/# Fichiers système.DS_StoreThumbs.db# PyInstaller (si vous empaquetez les tests)*.spec# Surcharges de configuration localeconfig/local.yamlQuelques notes sur ce qui est exclu :
- Les fichiers
.envcontiennent des clés API. Ne les commitez jamais. Incluez un.env.exampleavec des valeurs fictives pour que les nouveaux membres de l'équipe sachent quoi configurer. logs/ettest_output/sont générés par exécution. Leur place est dans TofuPilot, pas dans Git.cal_data/contient les données de calibration spécifiques à la station. Elles n'ont pas leur place dans le dépôt des scripts de test.config/local.yamlest pour les surcharges par développeur. Les configurations partagées (config/dev.yaml,config/production.yaml) restent suivies.