Testing

394 commits and 351 merged pull requests since September 3, from implementation and review agents running against AL Runner continuously since Saturday. What came out of it: a Windows cross-check that caught a real BC-on-Linux gap, a first honest measurement of test coverage against Microsoft's own test suite, and one hang bug traced to a report running 101,000 extra times.

Why I built a separate test suite that runs against a real BC service tier instead of AL Runner's in-memory emulator: 101 merged PRs and 566 AL files identifying exact AL language behavior, so AL Runner has a known-correct answer to match and I find out fast if Microsoft ever changes that behavior.

v2.4.0 through v2.10.0: you can now hydrate the runner's in-memory database from a real BC backup and test against actual Cronus data, breakpoint debugging is back, coverage can now be attributed per test for mutation testing, and one change that fails runs the old runner used to let through.

AL Runner's CI tooling got a week of hardening after a squash-merge bug ate a required check, the Linux fast lane fixed two bugs that only showed up on real pipelines, OpenPageInspection got its first update in two years, and I shipped Azure CLI auth to navapi, someone else's project.

AL Runner's dedicated post already covered v2.2/v2.3, but releases now gate on tests too; pushing the Linux fast lane onto a second repo surfaced a Windows PowerShell 5.1 JSON bug that had silently broken CI on two repos since day one; a graphify-al fork that had drifted 677 commits behind upstream got resynced, catching a live dependency landmine along the way; and a few smaller fixes landed in a WordPress migration script and in vsc-lintercop's LinterCop-to-ALCops migration notice.

Since the v2 cutover: code coverage for your AL test runs, running a snippet of AL without writing a codeunit for it, a watch mode that no longer reports fake failures mid-save, and about 130 fixes to places where the runner's behavior didn't match real BC. Plus shoutouts to the two AL developers whose bug reports drove most of them.

AL Runner shipped ~85 PRs closing correctness gaps and hardening the pipeline, bc-code-atlas's global_id now lets a self-hosted instance bridge into the public one to follow calls into Microsoft's base app, the AL Language Tests suite grew by answering AL Runner's own open questions, and the Linux fast lane got a week of real-world hardening.

v1 worked for the use cases it was built for. Companies actually using it told me that wasn't enough — most real extensions can't be unit tested at all without running against real Microsoft or ISV code. That feedback drove a clean v2 cut. It also changed how the runner fails: anything it can't support now throws loudly instead of quietly passing.

Live stream deep-dive into Business Central indirect permissions — what causes runtime permission errors, how to fix them with the Permissions property

Live code review of Microsoft's AI Test Toolkit PR in BCApps: fixing LinterCop violations, refactoring N+1 queries with FlowFields, and contributing back

Stefan Maroń and Christian Hovenbitzer argue at BC TechDays 2024 that Validate() should be the default in AL — not the exception — covering performance myths, chained validates, temp table pitfalls, and the cases where assignment is actually fine.

Catch AL validation errors including hidden Validate commits without side-effects — using the BC test framework as a reliable transaction rollback sandbox.

When to use API Queries vs API Pages vs OData Bound Actions in Business Central — a practical approach to building readable, testable, and performant

A look at the open-source GoLiveChecklisting app for Business Central — an extensible framework to script and validate data quality checks before going