Tests d’intégration pour les pipelines d’agents
Tests de bout en bout contre des services réels dans des environnements de test isolés.
Tests d’intégration pour les pipelines d’agents est une leçon AI Agents gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage AI Agents, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours AI Agents comprend 4 leçons au total.
Que sont les tests d'intégration pour les agents ?
Les tests unitaires vérifient des composants individuels de manière isolée. Les tests d'intégration vérifient que plusieurs composants fonctionnent correctement ensemble dans un environnement réel ou presque réel.
Pour les agents, cela signifie exécuter l'ensemble de la chaîne de traitement — appels LLM, exécution des outils et stockage des données — avec des services réels ou en bac à sable.
Structure d'un test de bout en bout
Un test d'agent de bout en bout envoie une requête réelle à travers toute la chaîne de traitement et valide le résultat final. Exécutez ces tests dans un environnement en bac à sable — jamais sur votre base de données de production ni avec les données réelles des utilisateurs.
import pytest
# Mark as integration test — skipped in fast unit test runs
@pytest.mark.integration
def test_research_agent_full_pipeline():
from myagent import ResearchAgent
agent = ResearchAgent(
openai_api_key='YOUR_TEST_KEY',
search_api_key='YOUR_TEST_KEY'
)
result = agent.run('What is the population of Tokyo?')
# Structural assertions — not exact string matching
assert isinstance(result, dict)
assert result['status'] == 'completed'
assert 'tokyo' in result['answer'].lower() or 'japan' in result['answer'].lower()
assert len(result['sources']) >= 1Isolation des données de test
Les tests d'intégration ne doivent pas polluer les données partagées. Utilisez des bases de données de test dédiées, des espaces de noms isolés ou des données temporaires qui sont supprimées après le test. N'écrivez jamais de données de test dans les tables de production.
import os
import pytest
# Use a separate test database URL
@pytest.fixture(scope='session')
def test_db():
test_db_url = os.environ.get(
'TEST_DATABASE_URL',
'postgresql://localhost/myagent_test' # separate test DB
)
# Set up test schema
from myagent.database import create_tables
create_tables(test_db_url)
yield test_db_url
# Tear down after all tests in the session
from myagent.database import drop_tables
drop_tables(test_db_url)Nettoyage après chaque test
Chaque test d'intégration doit supprimer toutes les données qu'il a créées. Utilisez le modèle de fonction de préparation avec yield de pytest : effectuez la préparation avant yield, puis le nettoyage après. Les tests restent ainsi indépendants et peuvent être exécutés dans n'importe quel ordre.
import pytest
@pytest.fixture
def clean_agent_memory(test_db):
# No setup needed — DB starts empty
yield
# Cleanup: delete any records created during this test
from myagent.database import clear_conversation_history
clear_conversation_history(test_db)
@pytest.mark.integration
def test_agent_stores_conversation(clean_agent_memory, test_db):
from myagent import Agent
agent = Agent(db_url=test_db)
agent.run('Remember that my name is Alex')
history = agent.get_history()
assert len(history) > 0
assert any('Alex' in str(msg) for msg in history)
# clean_agent_memory fixture deletes these after the testServices en bac à sable : clés d'API de test
Utilisez des clés d'API de test dédiées, avec des permissions et des quotas limités, pour les tests d'intégration. N'utilisez jamais de clés de production dans CI. Stockez les clés de test dans les variables d'environnement de CI, et non dans le code.
import os
import pytest
# Skip integration tests if test keys are not configured
def requires_integration_keys():
return pytest.mark.skipif(
not os.environ.get('OPENAI_TEST_KEY'),
reason='Integration test keys not configured'
)
@requires_integration_keys()
@pytest.mark.integration
def test_live_weather_tool():
from myagent.tools import get_weather
result = get_weather(city='London', unit='celsius')
assert result['success'] is True
assert 'temperature' in result
assert isinstance(result['temperature'], (int, float))Utiliser Docker pour les bases de données en bac à sable
Pour les tests d'intégration qui nécessitent une véritable base de données, démarrez un conteneur Docker pour la session de test. Vous disposez ainsi à chaque fois d'une base de données propre et isolée, sans conflits avec votre base de données de développement.
# conftest.py — docker-based test database
import subprocess
import pytest
@pytest.fixture(scope='session')
def docker_postgres():
container_id = subprocess.check_output([
'docker', 'run', '-d',
'-e', 'POSTGRES_PASSWORD=test',
'-e', 'POSTGRES_DB=agent_test',
'-p', '5434:5432', # use non-standard port to avoid conflicts
'postgres:15'
]).decode().strip()
import time
time.sleep(2) # wait for Postgres to start
yield 'postgresql://postgres:test@localhost:5434/agent_test'
subprocess.run(['docker', 'stop', container_id])
subprocess.run(['docker', 'rm', container_id])Configurations de test propres à chaque environnement
Les tests d'intégration nécessitent des configurations différentes pour les environnements local, CI et de préproduction. Utilisez des variables d'environnement et une fonction utilitaire de configuration pour sélectionner automatiquement les bons paramètres.
import os
def get_test_config() -> dict:
env = os.environ.get('TEST_ENV', 'local')
configs = {
'local': {
'db_url': 'postgresql://localhost/agent_test',
'openai_key': os.environ.get('OPENAI_TEST_KEY', ''),
'use_real_llm': False # use mocks locally
},
'ci': {
'db_url': os.environ.get('CI_DATABASE_URL', ''),
'openai_key': os.environ.get('CI_OPENAI_KEY', ''),
'use_real_llm': True # use real LLM in CI integration tests
},
'staging': {
'db_url': os.environ.get('STAGING_DATABASE_URL', ''),
'openai_key': os.environ.get('STAGING_OPENAI_KEY', ''),
'use_real_llm': True
}
}
return configs[env]
config = get_test_config()
print(f"TEST_ENV not set -> using '{os.environ.get('TEST_ENV', 'local')}' config")
print(f"DB URL : {config['db_url']}")
print(f"Use real LLM : {config['use_real_llm']}")
Marqueurs pytest pour sélectionner les tests
Utilisez des marqueurs pytest personnalisés pour catégoriser les tests et n'exécuter que le sous-ensemble pertinent. Configurez les marqueurs dans pytest.ini et utilisez -m sur la ligne de commande pour les sélectionner.
# pytest.ini
# [pytest]
# markers =
# unit: Fast unit tests with mocked dependencies
# integration: Slower tests with real or sandboxed services
# expensive: Tests that make real LLM calls and cost money
# Run only unit tests (fast CI check):
# pytest -m unit
# Run only integration tests:
# pytest -m integration
# Run everything except expensive tests:
# pytest -m 'not expensive'
# In test files:
import pytest
@pytest.mark.unit
def test_tool_format():
pass # fast, no external calls
@pytest.mark.integration
@pytest.mark.expensive
def test_with_real_llm():
pass # slow, costs tokensExécuter les tests d'intégration dans CI
Configurez votre chaîne de traitement CI (GitHub Actions, GitLab CI) pour exécuter les tests unitaires à chaque envoi et les tests d'intégration selon un calendrier ou avant les mises en production. Cela permet d'équilibrer rapidité et couverture.
# .github/workflows/test.yml (abbreviated)
# name: Tests
# on:
# push:
# branches: [main, develop]
# schedule:
# - cron: '0 2 * * *' # nightly integration tests
#
# jobs:
# unit-tests:
# runs-on: ubuntu-latest
# steps:
# - uses: actions/checkout@v3
# - run: pip install -r requirements.txt
# - run: pytest -m unit --tb=short
#
# integration-tests:
# if: github.event_name == 'schedule'
# env:
# CI_OPENAI_KEY: ${{ secrets.CI_OPENAI_KEY }}
# CI_DATABASE_URL: ${{ secrets.CI_DATABASE_URL }}
# steps:
# - run: pytest -m integration --tb=long
print('Unit tests on every push, integration tests nightly')Mesurer la couverture des tests pour les agents
Utilisez pytest-cov pour mesurer quelles lignes du code de votre agent sont couvertes par les tests. Visez une couverture élevée des fonctions d'outils et de la logique d'orchestration de l'agent, même si les appels LLM sont simulés.
# Install: pip install pytest-cov
# Run tests with coverage report:
# pytest --cov=myagent --cov-report=html -m unit
# This generates an HTML report showing which lines are untested
# Uncovered lines in the agent loop are high-risk areas
# Example coverage config in pyproject.toml:
# [tool.coverage.run]
# omit = ["tests/*", "scripts/*"]
#
# [tool.coverage.report]
# fail_under = 80 # fail if coverage drops below 80%
print('Coverage reports highlight untested code paths in your agent')Résumé des bonnes pratiques pour les tests d'intégration
Règles essentielles pour des tests d'intégration d'agents fiables :
- Utilisez toujours des bases de données de test distinctes — jamais la base de production
- Nettoyez les données de test après chaque test avec des fonctions de préparation utilisant
yield - Utilisez des clés d'API de test dédiées avec des quotas limités
- Utilisez des marqueurs pytest pour séparer les tests unitaires rapides des tests d'intégration lents
- Exécutez les tests unitaires à chaque envoi et les tests d'intégration selon un calendrier
- Utilisez Docker pour des environnements de base de données propres et jetables
Vérification des connaissances : tests d'intégration
Testez votre compréhension des tests d'intégration pour les chaînes de traitement d'agents.
Récapitulatif : tests d'intégration pour les chaînes de traitement d'agents
Vous disposez maintenant des connaissances nécessaires pour créer une suite complète et fiable de tests d'intégration :
- Utilisez
@pytest.mark.integrationpour séparer les tests lents des tests unitaires rapides - Isolez les données de test avec des bases de données dédiées et des fonctions de nettoyage
- Utilisez Docker ou des services en bac à sable pour disposer d'environnements propres
- Configurez les clés d'API propres aux tests via des variables d'environnement
- Exécutez les tests unitaires à chaque validation et les tests d'intégration chaque nuit dans CI
- Mesurez la couverture avec
pytest-covpour repérer les chemins non testés
Une pyramide de tests bien organisée permet à votre agent de rester fiable à mesure qu'il évolue.
Questions Fréquemment Posées
La leçon « Tests d’intégration pour les pipelines d’agents » est-elle gratuite ?
Oui — le texte complet de « Tests d’intégration pour les pipelines d’agents » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours AI Agents, passe à CoddyKit PRO. Le cours AI Agents comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Tests d’intégration pour les pipelines d’agents » ?
Tests de bout en bout contre des services réels dans des environnements de test isolés. Tu pratiques AI Agents avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer AI Agents ?
Aucune expérience préalable n'est requise. AI Agents sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.
Combien de temps prend la leçon « Tests d’intégration pour les pipelines d’agents » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon AI Agents ?
Oui. Chaque leçon AI Agents inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Pourquoi tester les agents est différent
- Simuler les appels aux LLM dans les tests
- Tester les agents par assertions
- Tests d’intégration pour les pipelines d’agents