Las pruebas de herramientas son pruebas de integración

Las herramientas son endpoints, así que pruébalas a través del servidor y no llamando a la clase:

AgentServer::tool(CreateSiteTool::class, [
    'url' => 'fails-to-provision',
    'email' => 'owner@webplo.com',
    'about' => 'Fail Site',
    'verification_token' => $token,
]);

Eso ejercita registro, esquema, validación y manejador juntos —el mismo camino que recorre un modelo. Llamar a handle() directamente se salta justo las partes que más fácilmente están mal configuradas.

Lo que además hace testable el registro, y eso importa dado el capítulo 11: una prueba que afirma que una herramienta interna no está en el conjunto publicado es una línea, y es lo único que separa «decidimos no publicar esto» de que alguien la añada al array dentro de seis meses.

Prueba las compensaciones, no el camino feliz

Esta es la prueba que conservaría si sólo pudiera conservar una:

it('restores the verification token and leaves no row when the platform create fails', function () {
    // … arrange a lead and a verified-email token …

    AgentServer::tool(CreateSiteTool::class, [/* … */]);

    // The single-use token is restored so the user can retry without
    // re-verifying, and the rolled-back provisioning row is not left behind.
    expect(Cache::get("verified-email:{$token}"))->not->toBeNull();
    expect(ProvisioningSite::query()->count())->toBe(0);
});

Dos aserciones, y entre ambas codifican todo el capítulo 10. El servicio externo falla; después, la verificación del usuario sigue sirviendo y no hay una fila huérfana ocupando su URL.

Fíjate en lo que hace posible esta prueba: todo el fichero simula un 500 para cada petición saliente. El camino de fallo merece su propio fichero de pruebas, con el fallo dispuesto una vez en beforeEach, en lugar de una prueba triste escondida entre veinte alegres.

Y fíjate en lo que no afirma: la redacción del mensaje de error. Afirma el estado del mundo después, que es lo que experimenta el usuario.

Las pruebas de contrato ganan a las de salida

El capítulo 2 presentó el par que ata el prompt al esquema, y merecen estar en cualquier lista de las pruebas más valiosas: comprobar que el prompt declara cada sección que el esquema exige, y que el resource expone exactamente la unión del esquema. Sin tokens, milisegundos, y atrapan la deriva concreta que nada más puede ver.

La forma general: comprueba que dos descripciones del mismo contrato siguen coincidiendo. Prompt y validador. Esquema de herramienta y validación de herramienta. Enum en una herramienta y enum en el servicio de detrás.