AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 16.06.2019, 16:19   #1  
Blog bot is offline
Blog bot
Участник
 
22,389 / 772 (70) +++++++
Регистрация: 28.10.2006
jaestevan: Acceptance Test Libraries (ATL) para Dynamics 365 for Finance and Operations
Источник: https://www.jaestevan.com/acceptance...nd-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:

[cc_xpp]// Create sales order linevar 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[/cc_xpp]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:

[cc_xpp]// Validate that we have one inventory transaction for the sales order linesalesOrder.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.');[/cc_xpp]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.



Источник: https://www.jaestevan.com/acceptance...nd-operations/
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
jaestevan: Trabajando con la máquina virtual de desarrollo local en Dynamics 365 for Operations Blog bot DAX Blogs 0 24.06.2017 22:11
jaestevan: Microsoft Dynamics 365 for Operations Blog bot DAX Blogs 0 02.11.2016 01:11
jaestevan: Dynamics 365, AppSource, PowerApps y compañía… ¿Qué esperar del futuro de los ERP en Microsoft? Blog bot DAX Blogs 0 26.07.2016 22:11
Platform updates overview - 3.70.B - NAV2009 R2 Blog bot Dynamics CRM: Blogs 0 07.02.2011 22:06
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 09:51.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.