La IA, en tu trabajo.

Qué cambia y cuándo está disponible

Las notas oficiales de la actualización 29.0 clasifican como disponibilidad general las suites AL extensibles y basadas en datos, la ejecución de pruebas por línea de comandos y CI/CD, y Page Scripting. Para clientes online existentes, el administrador programa la actualización dentro de una ventana que termina en febrero de 2027; el anuncio no acredita que un entorno concreto ya tenga BC29.

Datos reutilizables y ciclo de vida en AL

La guía de pruebas AL documenta TestDataSource para ejecutar un método con varios contextos suministrados por una codeunit que implementa ITestDataSource. Cada caso tiene un identificador estable. TestHandlers e ITestHandler permiten compartir callbacks del ciclo de pruebas, por ejemplo para registro o limpieza.

Estas API requieren runtime 18.0. La misma guía conserva avisos de preview para ellas, en discrepancia con el resumen de BC29. Conservamos esa incertidumbre: el ejemplo siguiente es conceptual y no acredita compatibilidad con una combinación concreta de compilador, símbolos y servidor.

Ejecución, requisitos y límites

ALTool incorpora runtests para ejecutar codeunits de prueba desde línea de comandos. Permite seleccionar una codeunit o un lote con --testgroups y devuelve resultados JSON y un código de salida para el pipeline. Con el alias al del paquete AL Development Tools, una invocación sería: `al runtests 50100 --project ./MyApp`. Presupone conexión configurada y la codeunit 50100 publicada; no se ha ejecutado para este artículo.

Para el recorrido visible, Page Scripting graba y reproduce acciones, valida campos y textos de diálogos y guarda YAML. Requiere los permisos PAGESCRIPTING - REC y PAGESCRIPTING - PLAY, o equivalentes. Para pipelines, la guía documenta @microsoft/bc-replay, Node.js y PowerShell. Ese reproductor no admite MFA. La herramienta tampoco automatiza complementos de control ni informes Power BI incrustados.

Las restricciones de las pruebas AL impiden ejecutarlas en producción online. En sandbox online no se permiten grandes volúmenes ni métodos de más de 15 minutos; Microsoft recomienda limitar la actividad a una o dos horas diarias. Para suites grandes y puertas CI/CD recomienda entornos de desarrollo en contenedores.

Ejemplo ficticio: una regla de descuentos

Ejemplo de Nexo, ajeno a la lógica estándar del producto: una extensión aplica un descuento del 5 % al alcanzar 10 unidades. El precio unitario se fija en 100 €, sin impuestos ni otros descuentos. Las cantidades deben ser enteros positivos; cero se rechaza. La tabla expresa resultados esperados, sin ejecuciones reales.

En este diseño, AL comprobaría el cálculo y el rechazo de cantidades inválidas. La grabación recorrería la introducción de la línea y validaría los valores visibles o el mensaje acordado. El equipo prepararía los casos AL y la grabación para esos mismos criterios.

Lectura de Nexo: acordar la aceptación

Nuestra interpretación es que compartir los casos puede facilitar la conversación entre desarrollo y perfiles funcionales. Proponemos un piloto pequeño con tres decisiones explícitas:

Un piloto así permitiría evaluar si ambos niveles ayudan a discutir la misma regla. Un resultado satisfactorio quedaría limitado a los casos y recorridos ejecutados; no demostraría cobertura completa ni sustituiría la aceptación humana.

• Acordar la regla, sus límites y los resultados esperados con el responsable funcional antes de grabar.
• Preparar datos y un estado inicial reproducibles en el entorno de pruebas elegido.
• Versionar los casos AL y las grabaciones junto al cambio, conservar los resultados por caso y revisar los fallos antes de aceptar.