AI, in your work.

What changes and when it is available

The official update 29.0 notes list extensible, data-driven AL test suites, command-line and CI/CD test execution, and Page Scripting as generally available. For existing online customers, administrators schedule the update within a window ending in February 2027; the announcement does not establish that a particular environment already runs BC29.

Reusable data and test lifecycle in AL

The AL testing guide documents TestDataSource for running a method with multiple contexts supplied by a codeunit implementing ITestDataSource. Each case has a stable identifier. TestHandlers and ITestHandler provide shared test lifecycle callbacks, for example for logging or cleanup.

These APIs require runtime 18.0. The same guide retains preview notices for them, conflicting with the BC29 overview. We retain that uncertainty: the following example is conceptual and does not establish compatibility with a particular combination of compiler, symbols and server.

Execution, requirements and limitations

ALTool includes runtests for executing test codeunits from the command line. It supports selecting a codeunit or a batch through --testgroups and returns JSON results and a process exit code for the pipeline. Using the al alias from the AL Development Tools package, an invocation would be: `al runtests 50100 --project ./MyApp`. This assumes a configured connection and deployed codeunit 50100; it has not been executed for this article.

For the visible journey, Page Scripting records and replays actions, validates fields and dialog text, and saves YAML. It requires PAGESCRIPTING - REC and PAGESCRIPTING - PLAY permissions, or equivalent permissions. For pipelines, the guide documents @microsoft/bc-replay, Node.js and PowerShell. That player does not support MFA. The tool also cannot automate control add-ins or embedded Power BI reports.

The AL testing restrictions prohibit running these tests in online production. Online sandboxes prohibit large test volumes and methods exceeding 15 minutes; Microsoft recommends limiting testing to one or two hours daily. For large suites and CI/CD gates, it recommends container-based development environments.

Fictional example: a discount rule

This Nexo example is separate from the product's standard business logic: an extension applies a 5% discount at 10 units or more. The unit price is fixed at €100, excluding tax and other discounts. Quantities must be positive integers; zero is rejected. The table describes expected outcomes, with no actual test execution.

In this design, AL would check the calculation and rejection of invalid quantities. The recording would follow line entry and validate the visible values or agreed message. The team would prepare AL cases and a recording for those same criteria.

Nexo's interpretation: agreeing on acceptance

Our interpretation is that shared cases could help developers and functional colleagues discuss acceptance. We propose a small pilot with three explicit decisions:

Such a pilot would allow the team to assess whether both layers help discuss the same rule. A successful result would cover only the cases and journeys executed; it would not demonstrate complete coverage or replace human acceptance.

• Agree on the rule, its boundaries and expected outcomes with the functional owner before recording.
• Prepare reproducible data and an initial state in the chosen test environment.
• Version AL cases and recordings alongside the change, retain results by case, and review failures before acceptance.