Teste deine Agenten,
bevor sie live gehen.
Definiere Tests in YAML unter tests/ und führe sie in der Connic-Runtime mit echten Verbindungen aus. Starte sie bei Bedarf mit connic test oder lass sie automatisch vor dem Deployment laufen.
Testing-Dokumentation lesentests/invoice-processor.yaml
- Rechnungssumme extrahiert312ms
- amount > 04ms
- currency in [EUR, USD]6ms
- Umsatzsteuer korrekt berechnet18ms
- Anbietername extrahiert11ms
Nutze das Connic-Testframework direkt in der Runtime
Führe deine Tests dort aus, wo auch deine Agenten laufen. Das Connic-Testframework nutzt die echte Connic-Runtime und prüft Antworten und Tool-Aufrufe anhand deiner YAML-Testfälle.
version: "1.0"
defaults:
runs: 5 # den Agenten je Case 5-mal aufrufen
success_threshold: 80 # 4/5 müssen zum Bestehen des Cases erfolgreich sein
timeout_s: 60 # gesamte verstrichene Zeit je Aufruf
tests:
- name: extracts_invoice_total
payload: '{"message": "extract total", "doc_id": "INV-7821"}'
expected_result: output.total > 0 and output.currency in ("EUR", "USD")
expected_tool_calls:
- invoices.extract: invocations >= 1
expected_no_tool_calls:
- notifications.sendtests/invoice-processor.yaml
- extracts_invoice_total312ms
- expected_result bestanden (5/5)4ms
- invoices.extract 5/5-mal aufgerufen6ms
- notifications.send nicht aufgerufen4ms
- Erforderliche Erfolgsquote von 80 % erreicht2ms
Lege fest, wann ein Test bestanden ist
Prüfe mit Python-ähnlichen Ausdrücken, was dein Agent zurückgibt, welche Tools er aufruft und ob Fehler auftreten. Das Connic-Testframework nutzt dafür denselben sicheren Evaluator wie Tool-Bedingungen und Freigaberegeln.
Ein Python-ähnlicher Ausdruck prüft output, error und status. Unterstützt werden Zugriffe auf Attribute und Elemente, Vergleiche, boolesche Operatoren und Prüfungen auf enthaltene Werte.
Einfache Tool-Namen verlangen mindestens einen Aufruf. Alternativ sind Mappings mit genau einem Schlüssel wie {tool: invocations >= 5} möglich. Beide Formen lassen sich kombinieren.
Tool-Namen, die während des Runs NICHT aufgerufen werden dürfen. Erkennt Fälle, in denen der Agent ein Tool hätte überspringen sollen.
Der Testfall wird N-mal ausgeführt (1–100) und besteht, wenn mindestens der festgelegte Prozentsatz erfolgreich ist. So lassen sich Agenten mit schwankenden Antworten prüfen, ohne dass einzelne Abweichungen die gesamte Suite scheitern lassen.
Maximale verstrichene Zeit je Aufruf in Sekunden (1–3600). Ein Timeout zählt für die Erfolgsquote als fehlgeschlagener Run.
Dynamische Payload Builder können aus cleanup() False zurückgeben, um den Testfall fehlschlagen zu lassen. Sowohl diese Prüfung als auch die YAML-Prüfungen müssen bestehen. Damit lassen sich Anforderungen prüfen, die über die unterstützten Testausdrücke hinausgehen.
Für LLM-basierte Qualitätsbewertungen produktiver Runs werden Judges separat im Dashboard konfiguriert.
Starte Tests per CLI und prüfe neue Deployments automatisch
Prüfe Änderungen während der Entwicklung und nutze dieselben Tests in deiner CI-Pipeline. Connic prüft neue Deployments vor der Freigabe, damit fehlgeschlagene Tests den Release stoppen.
name: Agent Tests
on:
pull_request:
paths:
- "agents/**"
- "tools/**"
- "tests/**"
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: pip install connic
- run: connic test --env ${{ secrets.CONNIC_CI_ENV_ID }} --json
env:
CONNIC_API_KEY: ${{ secrets.CONNIC_API_KEY }}Vergleiche, was das Connic-Testframework für dich übernimmt
Sieh, welche Funktionen für deine Agententests bereits enthalten sind und was du bei anderen Testansätzen selbst ergänzen musst.
| Funktion | Connic | Spreadsheet eval | LangSmith eval | DIY pytest |
|---|---|---|---|---|
| Mit dem Agent-Projekt versioniert | Enthalten | Nicht enthalten | Teilweise | Enthalten |
| Läuft in CI | Enthalten | Nicht enthalten | Teilweise | Enthalten |
| Expression DSL für Output / Status / Error | Enthalten | Nicht enthalten | Teilweise | Enthalten |
| Prüfen, welche Tools aufgerufen oder übersprungen wurden | Enthalten | Nicht enthalten | Teilweise | Teilweise |
| Wiederholungen je Testfall und erforderliche Erfolgsquote für schwankende Modellantworten | Enthalten | Nicht enthalten | Teilweise | Teilweise |
| Dynamische Testdaten aus Python mit anschließender Bereinigung | Enthalten | Nicht enthalten | Nicht enthalten | Teilweise |
| Dieselbe Runtime, echtes Environment, echte Verbindungen | Enthalten | Nicht enthalten | Teilweise | Nicht enthalten |
| Automatisches Deploy Gate ohne CI-Konfiguration | Enthalten | Nicht enthalten | Nicht enthalten | Nicht enthalten |
Entdecke weitere Features
Environments
Konfiguration und Secrets je Environment.
Bridges
Private Dienste ohne eingehende Ports erreichen.
Verbindungen
Agenten mit den realen Systemen verbinden.
Judges
Jeden Run bewerten und Drift früh erkennen.
Observability
Jeden Schritt und jedes Token nachvollziehen.
Dev Server
Lokale Entwicklung mit Hot Reload.