Acceptance Test Libraries (ATL) para Dynamics 365 for Finance and Operations

Uno de los anuncios más emocionantes de los últimos meses (y no es poco decir, con lo rápido que avanzamos tras el OneVersion) para programadores de Microsoft Dynamics 365 for Finance and Operations es la ATL. Esta es la librería que el equipo de producto utiliza para desarrollar sus propios test (unitarios o, mejor, de integración) funcionales.

El framework de Unit Testing existe desde hace tiempo en Dynamics AX, pero era complicado utilizarlo debido a la complejidad de mantener los datos necesarios para la ejecución de las pruebas y permitir la creación de pruebas deterministas.

Esa librería se ha publicado en el PU27 aunque solo una pequeña parte. En el PU28 que esta a día de hoy en el programa de preview se han liberado muchas más clases, y algunos ejemplos, a los que voy a echar un vistazo aquí para ver de qué hablamos.

La documentación está en el siguiente enlace. De momento hay una buena introducción teórica aunque no muchos ejemplos, actualizaré este post cuando la cosa mejore:

De momento, quiero comentar por encima los ejemplos publicados en la preview del PU28:

Como decía, el principal problema de desarrollar pruebas de integración (pruebas funcionales por código) en versiones anteriores era lo desproporcionadamente complejo que resultaba mantener el juego de pruebas. ¿Qué ocurre si podemos ejecutar test deterministas en, prácticamente, cualquier entorno? Pues eso mejoraría las cosas bastante. ¿Qué pasa si además tengo cientos de clases helper para crear estos datos y comprobar los resultados? Pues tendría prácticamente resuelto todo el problema, ¿verdad?

Bueno, quizás no tanto. Pero, por ejemplo, la creación de un pedido de ventas (con sus artículos, inventario, cliente, almacenes, …) en puro X++ plano nos llevaría probablemente decenas o cientos de líneas de código. Este es el código publicado en los primeros ejemplos que se han liberado esta semana:

// Create sales order line
var salesOrderLine = salesOrder.addLine() // Add a new line on the sales order
    .setItem(item)                        // Using standard cost item
    .setQuantity(SalesQuantity)           // Set the sales quantity
    .setInventDims([warehouse])           // Using default warehouse - site will be defaulted based on warehouse the same way as in the UI
    .setPrice(UnitPrice)                  // Set the price
    .setDeliverNow(PackingSlipQuantity)   // Set the quantity that should be delivered
    .save();                              // Save the sales order line

Esta sintáxis fluida para la creación de las entidades que necesitamos para las pruebas es posible gracias a la gran cantidad de clases que incluyen esta librería y que facilitan estas acciones. En la clase original se crean valores por defecto para los objetos secundarios como el artículo o el almacén, así como variables para las cantidades (que luego debemos comprobar en el siguiente paso).

Bien, con esto creamos el pedido. Pero queremos comprobar que el pedido es correcto. ¡Esto es un test, aquí hemos venido a comprobar! No hay problema:

// Validate that we have one inventory transaction for the sales order line
salesOrder.lines().firstEntity().inventoryTransactions().assertExpectedLinesSet(AtlSpecifications::construct()
    .addSpec(inventoryTransactions.spec()      // Add one specification to the expected results
        .withItem(item)                        // Item should be the same as on the sales order line
        .withQty(-SalesQuantity)               // The quantity should be the same as the sales quantity
        .withStatusIssue(StatusIssue::OnOrder) // The status should be on order
        .withInventDims([warehouse]))          // The warehouse should be the same as on the sales order line
    , 'Inventory transactions after creating the sales order.');

Así de sencillo resulta validar que la acción anterior ha hecho lo que debería hacer (crear transacciones de cliente con los valores apropiados). Fácil, ¿no?

Quería compartir esto en modo de introducción a la librería, pero seguro que vuelvo por aquí con más detalles y mejores ejemplos. Las pruebas son una parte fundamental de la estrategia OneVersion, y el desarrollo de Tests va a ser fundamental en los próximos meses para el éxito de los proyectos.

Volveré también con el resto de las herramientas disponibles para Testing en F&O. De momento tienes una introducción rápida en el vídeo de mi charla del pasado Dynamics Saturday.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

jaestevan
Microsoft Dynamics AX MVP. Programador y consultor técnico de soluciones Microsoft Dynamics AX y Business Intelligence. Experiencia con Dynamics AX, SQL Server y lenguajes como VB6, .NET C#, PHP, Java, etc. para desarrollos de escritorio, PDA, sitios y servicios web, interfaces de integración, etc.