Leer la transcripción en español
0:00 · Apertura
Una breve historia sobre las pruebas de sistemas SAP, contada por tres personajes: un agente, un mensajero, un sistema real. Y sobre una mentalidad, el Spec-Test-Driven Development (STDD): lo que probamos se observa primero en el sistema real.
0:17 · Los personajes
Stedd es el agente de IA. Un sombrero por tarea: planificar, generar, verificar, reparar. MCP es el mensajero: lleva las peticiones a Robot Framework y trae las respuestas. Terra es el sistema SAP real. Son dos: Terra 2023, nuestro objetivo, y Terra A4H, su gemelo.
0:36 · La forma habitual
La mayoría de la automatización de pruebas parte de lo que suponemos que hace el sistema: un documento, un recuerdo, una captura de pantalla. La prueba se escribe a partir de la suposición, sin mirar el sistema. Se ejecuta. Se pone en verde. Pero al sistema real nunca se le preguntó: el mosaico no existe, la aplicación vive en otro sitio. Verde, y falso.
1:00 · De TDD a STDD
Quizá ya conozca TDD: rojo, verde, refactorizar. Primero la prueba, después el código. El STDD aplica la misma lógica un ladrillo antes: la spec va primero. En teoría, una spec es verde por defecto: nadie la prueba. El STDD la pone a prueba en el sistema real: roja donde se equivocaba, verde una vez observada. Solo entonces llega la prueba.
1:25 · Tres eslabones
El STDD es una cadena de tres eslabones. Cada uno impulsa al siguiente, y cada uno está controlado por un script. 1 · La spec, escrita en lenguaje humano y confrontada después con el sistema real por un agente, antes de cualquier código. 2 · La prueba, derivada de la spec tal como se observó, y sellada con la huella de la spec. 3 · La biblioteca, desarrollada a partir de lo que la prueba necesita: nunca un apaño oculto en la prueba. Tres scripts: agent_contract.py, check_spec_sync.py, check_conventions.py. Fallan de forma ruidosa.
1:59 · Un caso real: el escenario 4
Un caso real: el escenario 4, en Terra 2023 (ABAP Platform 2023): crear un viaje con una reserva, en Fiori. La spec es un brief en lenguaje llano: siete líneas, nada de código. Cualquier forma sirve: un objetivo, una user story, un escenario BDD… Este supone dos cosas: un mosaico del Launchpad abre la aplicación, y el objetivo es la demo cap-sflight.
2:25 · Eslabón 1 · la spec frente al sistema real
Eslabón 1. El agente planner, un LLM, confronta el brief con el sistema vivo, antes de escribir una sola prueba. No adivina. Envía a MCP: Robot Framework maneja SAP de verdad, el LLM solo lee las respuestas. Suposición 1, un mosaico del Launchpad: 62 intents comprobados en Terra 2023. Ninguno abre una aplicación de viajes. Refutada. Suposición 2, cap-sflight: una aplicación CAP local en el puerto 4004. No es este objetivo. Aquí, la aplicación es RAP: /DMO/UI_TRAVEL_D_D. La aplicación real existe de todos modos: 4136 viajes, y el servidor genera una vista previa de Fiori Elements… tras un error HTTP 500. La solución se lee en el propio código fuente del servidor: la dirección está ofuscada, +20 por carácter. Decodificada: HTTP 200. Antes de escribir nada: ¿se puede deshacer? Descartar un borrador exige If-Match. Probado y demostrado: reversible. Lado a lado: el brief tal como se suponía, la spec tal como se observó en Terra 2023, línea por línea. Ningún mosaico, otro objetivo, una moneda obligatoria que la pantalla oculta, un ID que se reasigna: nada de esto se podía adivinar. 12 desviaciones en total, cada una respaldada por una medición. Un humano las revisa antes de generar nada. La spec tal como se observó, con sus 12 desviaciones respecto al brief, se escribe, se sella con un sha256 y la revisa un humano. Se convierte en la fuente de verdad. Para recordar: la spec se observa, no se supone. Las sorpresas llegan antes de las pruebas, no después.
4:17 · Eslabón 2 · la prueba, derivada de la spec
Eslabón 2. El agente generator convierte la spec observada en una suite de Robot Framework, con vocabulario de negocio. Cada paso se ejecuta primero en Terra 2023, a través de MCP, y solo se escribe cuando funciona. Ningún localizador adivinado. La suite lleva la huella de la spec, su sha256: la prueba sabe exactamente de qué spec se derivó. Si cambia la spec sin regenerar, check_spec_sync.py rechaza la ejecución. Regenerada y revisada: de nuevo en fase. Un script, no una promesa. Para recordar: no se escribe nada que no se haya ejecutado antes, y la suite queda sellada a su spec.
5:02 · Eslabón 3 · la prueba impulsa la biblioteca
Eslabón 3. A veces la prueba necesita algo que la biblioteca aún no sabe hacer: un formato de fecha, una cabecera que falta… …entonces la carencia se convierte en un keyword de la biblioteca, con su prueba unitaria. Nunca un apaño en la prueba: check_conventions.py vigila. Seis capacidades, cada una con su prueba unitaria: fechas tecleadas en el formato propio del campo, If-Match, la release leída por HTTP, la dirección de la vista previa… La biblioteca se publica en PyPI, como robotframework-sapfx. El siguiente proyecto recibe las seis gratis. Para recordar: la prueba impulsa la biblioteca, y cada carencia cubierta allí ayuda al siguiente proyecto.
5:53 · Un verificador independiente
Stedd cambia de sombrero. El verificador lee el plan, la suite y las evidencias. No ejecuta nada. Su primer veredicto sobre la suite verde: no verificado. 13 reservas, 3 de ellas bloqueantes. Las 13 corregidas, y después una contrarrevisión: requiere un humano, 7 puntos más. Corregidos también. Cada guarda debe verse rechazar. Primero, la referencia en Terra 2023: release 758, 58 servicios. Después, la suite se apunta a Terra A4H, a propósito: mismo ID de sistema, mismo nombre de host que Terra 2023. Comparado: 754 ≠ 758, 38 ≠ 58, sin runtime de UI5. Todas las guardas rechazan. Visto, no supuesto. Segunda provocación: un borrador plantado a mano en Terra 2023. La guarda lo respetó, la limpieza lo borró. Encontrado, corregido, repetido. Para recordar: una guarda que nadie ha visto rechazar no prueba nada.
6:58 · Resultado
Resultado: 7 pruebas de 7 en Terra 2023. Cada viaje creado se elimina, y se demuestra que ha desaparecido, entidad por entidad. Generar costó 1,67 M de tokens de LLM, una sola vez. Repetir cuesta cero tokens: Python puro, en menos de cinco minutos.
7:19 · Cuando el sistema cambia
Un caso real, el 1 de septiembre: el Demo Kit público de OpenUI5 cambió su shell de la noche a la mañana. Ni una línea de nuestro repositorio se movió. La campaña cae a 8 de 12. El diagnóstico del healer: no es un localizador, el propio flujo cambió. La spec se marca como CADUCADA. El planner vuelve al objetivo real, reescribe la spec según lo que mide, y la suite la sigue: 12 de 12, sellada de nuevo. La otra rama, probada a ciegas en Terra A4H: una deriva de localizador inyectada a propósito. El healer lee la pantalla viva… …y corrige una línea de resources/. Pruebas tocadas: cero. Nueva ejecución: 7 de 7. El STDD es un bucle, no una cadena de montaje. El healer repara resources/, nunca la prueba. Un flujo que cambia vuelve a la spec, y la suite lo sigue.
8:15 · Conclusión
La spec primero, en lenguaje humano. La prueba a partir de la spec. La biblioteca a partir de la prueba. Cada eslabón vigilado por un script. Observado, derivado, vigilado, y mantenido vivo cuando el sistema cambia. Gracias por caminar con Stedd, MCP y Terra.
