What's new: Testability Enhancements (2026 release wave 2)

Overview

The video covers two additions to the AL testing framework. Data-driven testing lets a single test method run with several data sets, so coverage grows by adding data points instead of duplicating test methods. A custom data source implements an interface and returns a strongly-typed test context. The source can read from resource files, AL tables or web services. The feature is demoed in the VS Code test explorer, where individual test cases can be run and debugged.

Test handlers provide setup and teardown at several levels. They come in two kinds: opt-in handlers, declared on a test codeunit through a test handlers property, and default (global) handlers that run on every test. The video also describes using handlers to skip test cases, for example to manage token consumption and AI credits.

Key points

• Data-driven testing runs one test method against multiple data sets, so you add data points instead of copying test methods.
• A custom test data source implements an interface with two functions: one lists the test cases and one builds the test context. It can return a strongly-typed test context and read from resource files, AL tables or web services.
• Data-driven tests work with the VS Code test explorer, including selective test case execution and debugging, after the test has run once. They can also run through the AL tool and the AL MCP connection.
• The AI test toolkit does not use the new capabilities yet, so its tests cannot be run from VS Code. Migration is planned.
• Test handlers bring back setup and teardown hooks that were lost when moving from AL test runners to platform test runners.
• ITestHandler has hooks before and after the test codeunit, the test procedure and each data-driven test case. All methods have default implementations, so you override only the ones you need.
• Handlers are registered through enum extensions: extending the test handler enum gives opt-in handlers, and extending the default test handler enum gives global handlers that run on every test, including tests in other apps.

Features

A status with a roadmap link comes from the Microsoft 365 roadmap feature this part of the video covers (matched by Haiku; links Opus dropped are not used); other statuses need a status word in the video itself.

AL objects mentioned

As heard in the captions. A name that matches one object page by exact type and name links to it; the others stay as named.

• interface “ITestHandler” at 7:05
• interface “ITestContext” at 3:01

Not found in BC28-30: interface “ITestHandler”, interface “ITestContext”.

Quotes

• 0:32 “finally we have introduced it into ALE and this allows you for having just a single test point but with testing it with multiple”
• 1:03 “this is so critical that we can broaden our test um scope to such an extent that we gain the trust uh and confidence”
• 3:28 “So all of this is gives you the the flexibility of implementing just the data source that you uh want and need. So right”
• 4:21 “test handlers are a way for us to provide test setup and tear down functionality in ALE”
• 5:26 “we also have these default test handlers uh or I like to think of them as global test handlers because they run on every”
• 7:26 “a lot of these have well all of these have default implementations. This means that you know if you if you’re writing a test”
• 8:27 “these um test handlers are separate from the test toolkit events that are driven by AL test runners”
• 9:05 “one common use case nowadays for us internally is we use it for managing token consumption. So you might want to say hey u”

Disclaimers in the video

• 3:56 coming-later: AI test toolkit is not yet using these new capabilities which means that you are not able to run these from Visual Studio Code. Um but that’s just a matter of time. we are planning on migrating them to this new system.

Presenters (as heard): Thomas, Thaddius.