tests/

Jedes generierte Projekt erhält eine sofort lauffähige TestBox-Suite.

tests/

Jedes über bxAgents new generierte Projekt erhält einen sofort lauffähigen tests/-Ordner: eine tests/box.json (die eine testbox-Abhängigkeit deklariert) und tests/specs/AgentSpec.bx, eine Beispiel-Spec, die sofort besteht.

cd my-agent/tests
box install       # holt testbox/ nach tests/testbox
cd ..
bxAgents test

Eine Spec schreiben

bxModules.bxagents.models.testing.BaseAgentSpec erweitern (eine Unterklasse von testbox.system.BaseSpec), statt testbox.system.BaseSpec direkt:

// tests/specs/AgentSpec.bx
class extends="bxModules.bxagents.models.testing.BaseAgentSpec" {

	function run() {
		describe( "my-agent", function() {

			it( "responds to a greeting", function() {
				mockResponses( [ "Hello! How can I help you today?" ] )

				var response = agent.run( "Hi there" )

				expect( response ).toContainText( "Hello" )
			} )

		} )
	}

}

BaseAgentSpec baut den eigenen Agenten einmal pro Spec-Bündel (beforeAll()), gegen eine wegwerfbare Temp-Kopie des eigenen Projekts - es fasst nie das echte .build/app an, das Ausführen von Tests kann also nie einen echten build-/serve-/package-Zyklus stören (oder von ihm gestört werden). Der gebaute Agent wird als agent exponiert.

Gegen den Mock-Provider testen

Standardmäßig baut bxAgents test den eigenen Agenten über Agent.bxs test()-Umgebungs-Override (automatisch generiert):

// Agent.bx
function test() {
	return {
		model : "mock/mock-model"
	};
}

Das bedeutet, die eigenen Tests brauchen sofort weder API-Schlüssel noch Netzwerkzugriff - dieselbe mock-Provider-Konvention, die auch in BX Agents' eigener Testsuite durchgängig verwendet wird. Dieses Override bearbeiten, um eine Spec stattdessen gegen einen echten Provider laufen zu lassen (dafür ist ein echter API-Schlüssel in der Umgebung nötig, die die Tests ausführt).

mockResponses( responses )

Skriptet die nächsten Antworten des Agenten, der Reihe nach konsumiert - eine pro LLM-Roundtrip, einschließlich der Zwischenschritte einer Tool-Aufruf-Schleife:

mockResponses( [
	{ toolCalls: [ { name: "getWeather", arguments: { city: "Miami" } } ] },
	"It's sunny in Miami!"
] )

var response = agent.run( "What's the weather in Miami?" )

Ein bloßer String skriptet eine finale Antwort. Eine { toolCalls: [ { name, arguments } ] }-Struktur skriptet einen Tool-Aufruf-Turn - das benannte Tool wird tatsächlich echt ausgeführt (gegen die eigene echte Implementierung unter tools/), und sein echter Rückgabewert ist es, was der nächste Roundtrip sieht; nur die eigene Antwort des LLM wird skriptet, nie das Verhalten des Tools.

Custom Matcher

BaseAgentSpec registriert ein paar Matcher, zugeschnitten aufs Testen von Agentenverhalten, über TestBoxs eigenen Erweiterungspunkt addMatchers() - genau wie jeder eingebaute TestBox-Matcher verwenden, einschließlich Negation (notTo...):

expect( agent ).toHaveCalledTool( "getWeather" )
expect( agent ).notToHaveCalledTool( "getStockPrice" )

Tests ausführen

bxAgents test

Führt die eigenen tests/specs/** des Projekts über TestBox aus, in einem frischen Kindprozess (damit er nie um BoxLangs eigene Class-Mapping-Caches mit irgendetwas anderem konkurriert, das gerade läuft). Gibt Bundle-/Suite-/Spec-Zähler sowie Gesamtzahlen für bestanden/fehlgeschlagen/Fehler/übersprungen aus, plus eine Zeile pro Fehlschlag, und beendet mit einem Exit-Code ungleich null, falls etwas fehlgeschlagen ist - geeignet als CI-Gate vor deploy.