Versionner les tests matériels avec Git

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.

git_workflow.txt

main          ──●──●──●──●──●──●──  (tests prêts pour la production)
                    \        /
feature/add-  ──●──●──●──●          (nouveau test ou modification)
thermal-test

main 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 :

workflow_commands.sh

# Démarrer une nouvelle modification de test
git checkout -b feature/add-current-measurement

# Faites vos modifications, testez localement
git add tests/power_rail_fct.py
git commit -m "Add idle current measurement to power rail FCT"

# Poussez et créez une pull request pour revue
git push -u origin feature/add-current-measurement

# Après revue, fusionnez dans main
git checkout main
git pull
git merge feature/add-current-measurement
git push

Taguez les releases quand vous déployez sur les stations de production :

tagging.sh

# Taguer une release avant le déploiement en production
git tag -a v1.2.0 -m "Add thermal cycling test, update voltage limits for Rev C"
git push origin v1.2.0

Inté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.

git_version.py

import subprocess

def 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 info

Taguer 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.

test_with_version.py

import openhtf as htf
from openhtf.util import units
from tofupilot.openhtf import TofuPilot
from git_version import get_git_info

git_info = get_git_info()

# Avertir si l'exécution se fait avec des modifications non commitées en production
if 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.29

def 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.

.gitignore

# 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
*.csv
captures/
screenshots/

# Données de calibration des instruments (spécifiques à la station)
cal_data/
fixture_cal/

# Fichiers système
.DS_Store
Thumbs.db

# PyInstaller (si vous empaquetez les tests)
*.spec

# Surcharges de configuration locale
config/local.yaml

Quelques notes sur ce qui est exclu :

Les fichiers .env contiennent des clés API. Ne les commitez jamais. Incluez un .env.example avec des valeurs fictives pour que les nouveaux membres de l'équipe sachent quoi configurer.
logs/ et test_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.yaml est pour les surcharges par développeur. Les configurations partagées (config/dev.yaml, config/production.yaml) restent suivies.