Description
Please include the following with each issue:
1. Describe the bug
When running AL tests through al runtests, a standard Business Central validation error is returned in German even though System.GlobalLanguage() reports 1033 (English, United States) immediately before the validation.
Explicitly calling System.GlobalLanguage(1033) before the same validation makes the error English and the test passes.
The cause of the language selection is unknown. Is this expected behavior, and is there a way to control the test language centrally when using al runtests?
2. To Reproduce
-
Use a Business Central on-premises environment with German translations available.
-
Add the following codeunit to a test app with a dependency on the Microsoft Library Assert app.
-
Publish and install the test app.
-
Configure authentication for the development endpoint. For
UserPassword, setBC_SERVER_USERNAMEandBC_SERVER_PASSWORDas environment variables; do not include credentials in the command. -
Run the tests, replacing the server, instance and port with your environment's values:
al runtests 50100 ` --server 'http://<server>' ` --serverinstance '<instance>' ` --port 7049 ` --tenant default ` --authentication UserPassword ` --testmethods ReproDefaultTestLanguage ` --testmethods ReproExplicitEnglishLanguage
codeunit 50100 "Test Error Language Repro"
{
Subtype = Test;
TestPermissions = Disabled;
[Test]
procedure ReproDefaultTestLanguage()
var
Customer: Record Customer;
Assert: Codeunit Assert;
begin
Customer.Init();
// This assertion passes in the affected environment.
Assert.AreEqual(1033, System.GlobalLanguage(), 'Session language');
asserterror Customer.TestField("No.");
Assert.ExpectedError('must have a value');
end;
[Test]
procedure ReproExplicitEnglishLanguage()
var
Customer: Record Customer;
Assert: Codeunit Assert;
begin
Customer.Init();
System.GlobalLanguage(1033);
asserterror Customer.TestField("No.");
Assert.ExpectedError('must have a value');
end;
}The test methods were verified within an existing test codeunit. The standalone codeunit above is an adaptation for reproduction.
Additional observations from the affected environment:
- The server's
ServicesLanguagewasen-US;DefaultLanguagewas empty. - Setting the test user's Language ID to
1033and restarting the service tier did not resolve the original failures. The user's Locale ID remained2055. - Deleting the user personalization record and restarting also did not resolve them.
- The captured developer-endpoint request did not send an
Accept-Languageheader. InjectingAccept-Language: en-USthrough a local proxy did not change the result. - The observed
TestRunnerHubinitialization and test-run messages did not contain a language parameter. The CLI help does not expose a language option.
3. Expected behavior
When System.GlobalLanguage() reports 1033, the validation error should be in English, or the behavior and the way to configure the test language should be documented.
Both test methods should produce the same result when the reported language is already 1033.
4. Actual behavior
ReproDefaultTestLanguage passes the language assertion but fails the error assertion:
Assert.ExpectedError failed. Expected: must have a value.
Actual: 'No.' muss in 'Customer' einen Wert enthalten: 'No.='.
Der Wert darf nicht null oder leer sein.
ReproExplicitEnglishLanguage passes after explicitly setting System.GlobalLanguage(1033).
Result: 1 passed, 1 failed, 0 skipped.
5. Versions:
- AL CLI:
30.0.44.47290+3c92cdc4ab04cab72c5db0204d4d91609bd6dc04(microsoft.dynamics.businesscentral.development.tools 30.0.44.47290-beta) - Business Central: server
29.0.56990.0; Application, Base Application and System Application29.0.54011.57023 - Operating System:
- Windows - Windows 11 Enterprise, build
26200 - Linux
- MacOS
- Windows - Windows 11 Enterprise, build
Final Checklist
- Search the issue repository to ensure you are reporting a new issue
- Simplify your code around the issue to better isolate the problem
Activity