Automated testing took on a more critical role in the world of Dynamics 365 with the introduction of Continuous Updates (#OneVersion). Dynamics customers must have an ability to update their application frequently and test the solution in days and hours (not months and weeks). While RSAT (Regression Suite Automation Tool) is a decent starting point for testing activities, it definitely does not place most organizations in a position to have 100% coverage for all business and technical scenarios. Here comes ATL …
How do I create a test using the Acceptance Test Library (ATL)?
One of the most interesting features in the latest releases of Dynamics 365 for Finance and Operations (D365FO) is a powerful new testing interface released in version 10.0.3. The Acceptance Test Library, or ATL, is an API that interfaces the business logic and database layer in D365FO with the testing infrastructure available in Visual Studio. Microsoft has used this library for years internally, and now it is available for anyone extending the application.
As it resides in D365FO codebase, getting started with the ATL is as simple as creating a new class in a model referencing the ATL models. Microsoft have provided several example test case implementations along with the interface itself, and these provide a great view of how to create these tests.
The basic flow of a test using ATL is as follows:
- Initialize data
- Execute business logic
- Validate results
Initializing test data in the ATL is accomplished by using a “Factory” concept, similar to many other places in D365FO. Using classes within the ATL that mirror actual tables, you can have the Library instantiate various entities with default or manually provided data:
These statements may look a little alien to a seasoned D365FO developer, as the ATL is a “Fluent” library. This means that methods can be chained together into single statements that express what the statement is doing. In the example above, rather than populating five different parameter methods as is familiar in most areas of the system, the parameters are all set in a single statement by chaining their accessors together. This results in highly readable code that goes a long way to self-document tests.
Execute Business Logic
The ATL has also encapsulated business logic into simple methods that mirror real-world operations. These methods are very descriptive and allow you to test specific functionality without additional set-up. While the code is very simple here, the logic being executed within the ATL is actually the same code used by the system.
Finally, once business logic has been executed, the results of these operations can be validated by “Asserting” the correct values. This compares the expected values to what actually exists after the test, and then fails the test if there is a discrepancy.
The messages presented upon test failure are very precise and informative, including actual vs expected values, along with the exact line of code in the test that failed. Furthermore, it is possible to debug the tests themselves, as they are code, which assists in development and in troubleshooting live tests.
Running the tests can be accomplished from within Visual Studio by using the test explorer. This will find any tests you have opened and present them as a playlist that can be run. Using the test explorer, a whole battery of tests can be setup and run at once to fully test a new modification.
The Acceptance Test Library is a powerful new tool that allows for thorough testing of new code with minimal overhead. While it is not a replacement for user testing and automated testing through utilities such as the Regression Suite Automation Tool, it is highly useful for unit testing. Microsoft provides several sample tests that demonstrate the functionality well, but if you would like more information or a live demo of the tool, contact us today!
Check out Part 2 of this blog (ATL Code Generation Wizard) here:
Thanks for reading! You may also be interested in…