Business Central 29 ALTool Adds CLI Test Automation and JSON Results for CI/CD

The record is marked Launched, in the General Availability release ring, for Worldwide (Standard Multi-Tenant), with a GA date of October 2026. That's the headline. The details that matter for production pipelines are less clear, and they're covered below.

What Microsoft announced​

According to the roadmap entry, the new ALTool capability:

• Compiles, deploys and runs AL test projects from a script or a pipeline step.
• Returns structured JSON that includes individual test methods plus pass, fail and skip counts.
• Doesn't need the AL MCP server or a manually operated test client.
• Works the same way locally, so a developer's workstation and the build agent run tests with the same command.

Microsoft's stated benefit is that machine-readable output makes it easier to publish test results, enforce quality gates and diagnose failures in continuous integration.

There's also a reason this showed up as a roadmap card rather than a traditional release-plan page. Microsoft's Business Central release-plan pages now say Release Plans stopped being published in September 2026. New Dynamics 365, Power Platform and Dataverse capabilities now go to the AI at Work roadmap instead.

Summary: One command, used on a laptop or a build agent, that builds, deploys and tests AL code and returns JSON a pipeline can read.

Where ALTool came from​

ALTool isn't new. Microsoft Learn describes it as a command line tool used for compiling and packaging AL extensions for Business Central. It's useful for integration into CI/CD pipelines to automate the build and deployment process.

It has been picking up features steadily. In the 2026 release wave 1 plan, Microsoft enhanced the tool by adding the ability to launch an AL MCP server for use in agentic AL coding from the command line, as well as commands for working with workspaces and detecting symbol-only packages. The current command reference also lists a standalone language server and, for wave 2, profiling and snapshot-debugging MCP proxies.

Test execution is the obvious missing piece. Until now, ALTool could build your extension but couldn't tell you whether the extension worked.

The feature also appears to belong to the autumn release. WindowsForum previously reported that community blogger thinkaboutit.be's list of the version 29.0 preview contents includes ALTool command line testing, which works with CI pipelines, and a standalone AL language server for running language intelligence features outside Visual Studio Code. That fits the roadmap's October 2026 GA date, but it's a community preview listing, not a Microsoft version requirement.

Getting ALTool onto a build agent (documented today)​

Microsoft hasn't published the test command's syntax yet (see the open questions below). The installation route is documented, though, and you'll need it either way:

1. Install the Development Tools package as a .NET global tool. Microsoft's recommended command is:
   dotnet tool install --global Microsoft.Dynamics.BusinessCentral.Development.Tools
2. Use the al alias. The package provides the al alias so you can run ALTool commands without specifying the full path to altool.exe. This option is ideal for CI/CD pipelines and automated environments where a full Visual Studio Code installation isn't needed.
3. Or call the executable directly. On a machine with the AL extension installed, altool.exe sits in the extension's bin folder. Microsoft's example path is under .vscode\extensions\ms-dynamics-smb.al-<version>\bin\win32\. Swap al for the full path and everything else stays the same.
4. Check what your build actually supports. Run al help to list the available commands. If you don't see a test-related command, your agent has an older tools package.

Microsoft says the package is built for easy automation of build and deployment processes for your AL projects in Azure DevOps, GitHub Actions, or other automation platforms, and describes ALTool as a cross-platform tool for compiling, packaging, and managing AL extensions outside of Visual Studio Code.

One more prerequisite from the docs: to deploy code built using ALTool, you must sign up for a Dynamics 365 Business Central Sandbox tenant. A command that deploys before testing will need somewhere to deploy to.

Summary: Install the NuGet tool, confirm the test command shows up in al help, and have a sandbox ready.

How this differs from Test Explorer​

Don't confuse this with the Visual Studio Code Test Explorer integration that shipped earlier in 2026. They solve related problems, and they're documented separately.

Test Explorer has documented limitations. Its tests don't run under an AL test runner codeunit, so AI tests aren't supported. Tests that depend on test-runner setup or teardown events may fail. Isolation follows each test codeunit's RequiredTestIsolation property and defaults to codeunit-level isolation.

Those are Test Explorer's limits, not confirmed limits of the new CLI runner. Still, if your suite depends on custom test-runner codeunits, it's worth checking whether the ALTool path behaves the same way before you rely on it.

What Microsoft hasn't documented yet​

Microsoft's ALTool reference page, as inspected, doesn't yet cover the test feature. Missing details include:

• Command syntax and flags. No subcommand name, arguments or options are documented. Don't copy guessed syntax from forum posts into production YAML.
• The JSON schema. We know it includes test methods and pass/fail/skip counts. We don't know the field names, whether the schema is versioned, or whether it can be converted to JUnit or another format your CI system reads natively.
• Exit codes. Does a failed test make the process exit with a non-zero code? Do skipped tests? This is what decides whether a pipeline goes red without a parsing step.
• Authentication. The ALTool page documents headless authentication for its profiling and snapshot MCP proxies: a BC_ACCESS_TOKEN environment variable (obtainable via Azure CLI), a cached altool auth login token, or on-premises credentials. It's a plausible model for the test runner, but Microsoft hasn't confirmed it applies.
• Environment lifecycle. The roadmap doesn't say whether ALTool provisions or cleans up a test environment, or only targets one you already have.
• Supported targets. The card lists Worldwide multitenant only. On-premises and container support aren't stated.

Also remember that Microsoft's roadmap describes itself as estimated and subject to change. "Launched" with an October GA month doesn't mean every build agent has the bits today.

Before you rebuild your pipeline​

This is general advice, not feature-specific instructions from Microsoft:

1. Pin the tools package version on build agents so a silent update doesn't change your JSON output.
2. Test the gate logic on purpose. Commit a deliberately failing test and a deliberately skipped one, and confirm the pipeline behaves the way your policy says it should.
3. Point automation at sandboxes. Even if the CLI turns out to support more, deploying test apps to production is a bad idea.
4. Keep your current harness running alongside it until the new runner reliably reproduces its results across a few release cycles.
5. Treat the JSON as a build artifact. Archive it with the build so failures can be traced and compared over time.

The competition​

Microsoft isn't alone here. Community projects already work in this space. Stefan Maron's AL Runner says it can run Business Central AL unit tests in milliseconds — no BC service tier, no Docker, no SQL Server, no license required. That's a very different design, running code in-process rather than deploying it to a real environment. A first-party runner built into ALTool brings Microsoft support and a single toolchain, but it doesn't make those faster unit-testing approaches obsolete.

Bottom line​

For Business Central development teams, this is one of the more practical items in the wave 2 tooling updates. A single Microsoft-supported command that compiles, deploys, tests and returns JSON could replace a lot of custom pipeline scripting.

Until Microsoft publishes the command reference, though, "structured JSON" and "quality gates" are promises rather than a contract. Install the tools package, check al help on your agents, and watch the ALTool documentation page closely. Don't hand-write a JSON parser until you know the schema.