Het testen van agents is een volwaardige functie van het framework, geen bijzaak. Agent-Lab bevat twee complementaire harnesses waarmee je zowel het framework zelf kunt valideren als de agents die je erop bouwt:
- Integratietests testen het systeem tegen echte infrastructuur (Postgres, Redis, Keycloak, embeddings, headless Chrome) die op aanvraag wordt opgestart met testcontainers — en dekken externe services, databasebewerkingen, vector search en API-endpoints af.
- Agentsimulaties evalueren het gedrag van agents end-to-end tegen live LLM's, beoordeeld door een LLM-as-judge en in de tijd gevolgd in Langfuse en LangWatch.
De belangrijkste configuratie voor integratietests staat in tests/conftest.py; pas
die aan je omgeving aan.
Let op: integratietests en simulaties doen echte aanroepen naar externe services en kunnen kosten met zich meebrengen. Voer ze uit in een gecontroleerde omgeving en houd het gebruik in de gaten.
Integratietests
Vereist Docker (of een andere container-runtime) — de suite richt echte containers in via testcontainers.
make test_unit # fast lane: boots the app with no infrastructure
make test_integration # the full real-infrastructure suite
make test # both, with coverage (gate: 90%)De eerste uitvoering kan enkele minuten duren — Docker-images en embeddingmodellen
worden eenmalig gedownload. De coverage van agent_lab/ wordt in CI afgedwongen (SonarCloud).
De gescaffolde projecten doen hetzelfde: tests/ bevat smoketests zonder containers plus
een optionele testcontainers-suite.
Agentsimulaties
End-to-end-agentsimulaties staan in tests/simulation/ en roepen live LLM-providers
aan. Ze zijn gemarkeerd met agent_test en worden standaard overgeslagen; voer ze uit met:
make test_simulations
# or a single track:
make scenario_simulation
make langwatch_simulation
make langfuse_simulationDrie complementaire tracks delen de bootstrap-helpers voor agents, de judge en de
datasetdefinities onder tests/simulation/datasets/:
tests/simulation/scenario/— conversationele simulaties met het langwatch-scenario-framework: een gebruikerssimulator stuurt de agent aan terwijl een judge-agent de interactie beoordeelt.tests/simulation/langfuse/— datasetgestuurde experimenten met Langfuse-datasets. Elke run synchroniseert de datasetdefinities, roept de agent per item aan, beoordeelt de output met een client-side LLM-as-judge en legt de run en de scores vast in Langfuse, zodat je ze in de tijd kunt vergelijken. Wordt automatisch overgeslagen alsLANGFUSE_BASE_URL(of het verouderdeLANGFUSE_HOST),LANGFUSE_PUBLIC_KEYenLANGFUSE_SECRET_KEYniet zijn ingesteld.tests/simulation/langwatch/— dezelfde datasetexperimenten, gespiegeld naar LangWatch vialangwatch.experiment, waarbij per item de score van de judge wordt gelogd. Definities worden idempotent gesynchroniseerd naar één geconsolideerdesimulations-dataset (eendataset-kolom geeft de brondefinitie aan, omdat het gratis abonnement van LangWatch maximaal 3 datasets per project toestaat). Wordt automatisch overgeslagen alsLANGWATCH_ENDPOINTenLANGWATCH_API_KEYniet zijn ingesteld.
De referentieagents die in de tracks aan bod komen: de coordinator-planner-supervisor-, react RAG-, vision/document-, browserautomatiserings-, voice memos- en adaptive RAG-agents.
LLM-configuratie van judge en agent
De judge (en de gebruikerssimulator van scenario) gebruiken litellm-model-id's tegen elk OpenAI-API-compatibel endpoint:
| Omgevingsvariabele | Standaard | Doel |
|---|---|---|
SIMULATION_JUDGE_MODEL |
openai/gpt-5-nano |
litellm-model-id dat de LLM-as-judge gebruikt |
SIMULATION_JUDGE_API_BASE |
standaard van provider | eigen OpenAI-compatibel endpoint voor het judge-model |
SIMULATION_JUDGE_API_KEY |
standaard van provider | API-sleutel voor het eigen endpoint |
De geteste agents draaien op een standaard-LLM die wordt aangeboden door een willekeurig OpenAI-compatibel endpoint
(bijv. een inferentieserver in het LAN), per test ingericht door
tests/simulation/common/llm_factory.py. De uitzondering is de voice memos-agent,
die op OpenAI blijft (die heeft audio-invoer in de chat nodig). Embeddings blijven de
EMBEDDINGS_ENDPOINT-fallback gebruiken (de Ollama-testcontainer die bge-m3 aanbiedt),
passend bij de pgvector-dump. Het endpoint moet tool calling / structured
output ondersteunen voor de suites op basis van een supervisor (browserautomatisering, supervisor):
| Omgevingsvariabele | Standaard | Doel |
|---|---|---|
SIMULATION_LLM_MODEL |
geen (verplicht) | modeltag die de simulaties uitvoert (bijv. qwen3:30b) |
SIMULATION_LLM_API_BASE |
geen (verplicht) | OpenAI-compatibel endpoint dat het model aanbiedt |
SIMULATION_LLM_API_KEY |
dummy-key |
API-sleutel, als het endpoint er een vereist |
De evaluatieplatforms inrichten
make test_simulations (en de targets per track) voeren eerst de stap
sync_simulation_evals uit, die de datasetdefinities spiegelt naar elk
geconfigureerd platform. Om ook de server-side evaluatiesetup van Langfuse
in te richten (een LLM-verbinding voor het judge-model, een simulation_llm_as_judge-evaluator
en één evaluatieregel per simulatiedataset — zichtbaar in de sectie
Evaluations van Langfuse), voer je uit:
uv run python tests/setup_simulation_evals.pyHet script is idempotent en kan veilig opnieuw worden uitgevoerd.