Interpreter Test Reference — Overview

The ToolBox AL interpreter ships with an automated test suite that pins its behavior. This chapter is a reference to that suite: it lists every test and states what each one verifies, so you can see exactly which language behaviors are guaranteed — and read the tests as worked examples of correct ToolBox AL.

The tests live in the codeunit "Compiler Tests Hgd" (object 70310410, Subtype = Test) in the AL Compiler and Interpreter app (src/Tests/Test.al). There are 84 [Test] procedures covering expressions, types and conversion, control flow, procedures, parameterless calls, built-in functions, JSON, collections, arrays, codeunits, streams, records (including temporary records), and diagnostics.

How the Tests Run

Each test registers the interpreter, then runs one or more small ToolBox AL scripts through a helper and asserts on the result. The scripts are ordinary ToolBox AL — the same language you write in the editor.

The Compile Helper

Most assertions go through a Compile(source) helper that parses and runs a script and fails the test if the compiler or the runtime reports any diagnostic. The script itself raises error(...) when an expected value is wrong, so a green test means the script both compiled and produced the expected values.

// A representative line from the suite (ControlFlowTests):
Compile('var i : Integer; sum : Integer; begin sum := 0; for i := 1 to 10 do sum := sum + i; if sum <> 55 then error(''for to''); end;');

Assertion Helpers

Helper	What it checks
`Compile(source)`	Script compiles and runs with no diagnostics
`CompileExpectDiag(source, substr)`	Running the script raises a runtime diagnostic containing `substr`
`CompileExpectParseDiag(source, substr)`	The script fails to compile, with a diagnostic containing `substr`
`CompileExpectAnyDiag(source)`	The script raises some diagnostic (message text not pinned)
`CompileConsoleIs(source, expected)`	The script's console output equals `expected`
`TestEvalInteger/Decimal/Text/Code/Boolean/Date/Time/DateTime/Duration/Option/BigInteger`	An expression evaluates to the expected typed value

The Native-Mirror Pattern

Several tests are native mirrors: the same expressions are also run on Microsoft's own AL compiler and runtime (in "Compiler Tests Hgd" itself, and in the companion "Native Conversion Tests Hgd" codeunit in the ToolBox app). This proves the interpreter tests encode real AL semantics — if the interpreter and native AL ever disagree, exactly one of the paired tests fails and points at the drift.

Native-mirror and "native spec" tests include JsonNativeMirrorTests, ListDictNativeMirrorTests, ArrayNativeMirrorTests, DecimalToIntegerStoreTests, GuidDefaultTests, DateTimeRepresentationTests, EvaluateFailurePreservesTargetTests, FormatContainerTests, and FormatWithLengthTests.

Spec-First Audit Tests

A block of tests near the end pins specific bugs found in the 2026-07 interpreter audit. Each one isolates a single defect (with nearby regressions that already pass), so a failing run names the defect directly. These document subtle correctness rules — default return values, parameter size isolation, filter handling, and more.

Running the Suite

The tests are standard Business Central test procedures. Every [Test] in "Compiler Tests Hgd" is registered in the "Run All Tests Hgd" codeunit, which executes the full suite. Run them from the Business Central test tooling (Test Tool page or an AL test run) against a company that has demo data, since some record tests read the Customer table.

Chapter Map

The remaining sections group the 82 tests by area: