Add testing knowledge: UI handlers, table relations, asserterror, fixtures (P1+P2) (#62)

* Add testing knowledge: UI handlers, table relations, asserterror, fixtures (P1+P2)

Six BC-specific testing-domain knowledge articles in community/knowledge/testing/, each with .good.al/.bad.al samples:

- ui-calls-require-test-handlers
- tablerelation-requires-prerequisite-records
- handlers-enqueue-never-assert
- handlerfunctions-attribute-must-match-ui-path
- asserterror-needs-expectederror-and-code
- use-library-codeunits-for-test-fixtures

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Move testing knowledge from community to microsoft layer

Relocates the six P1+P2 testing-domain articles (18 files: .md + .good.al + .bad.al each) from community/knowledge/testing/ to microsoft/knowledge/testing/ per maintainer request. Pure git-mv rename; no content or frontmatter changes.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Address review: merge handler articles, adopt enqueue-driven pattern

Respond to @nikolakukrika's review on #62:

- Merge ui-calls-require-test-handlers, handlerfunctions-attribute-must-match-ui-path
  and handlers-enqueue-never-assert into a single ui-handlers-in-tests article.
- Adopt the enqueue-from-test / dequeue-and-assert-in-handler pattern using
  Assert.ExpectedConfirm/ExpectedMessage (substring match), with Initialize()
  clearing LibraryVariableStorage and AssertEmpty() proving exact call counts.
- asserterror sample now uses Assert.ExpectedTestFieldError + FieldCaption instead
  of hardcoded message/code; article text points to the library helpers.
- Drop the tablerelation article and fold its test-relevant ordering point
  (relations checked on Validate/Insert(true); build parents first) into
  use-library-codeunits-for-test-fixtures.

Article count 198 -> 195.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Jesper Schulz-Wedde <jesper.schulzwedde@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

microsoft/knowledge/testing/ui-handlers-in-tests.bad.al

@@ -0,0 +1,43 @@
+codeunit 50401 "Test UI Handlers Bad"
+{
+    Subtype = Test;
+
+    // Several wiring mistakes, each of which fails at runtime rather than as a
+    // clean assertion the reviewer can read:
+    //  * A UI call with no listed handler -> "unhandled UI" abort (the Message
+    //    below has no handler).
+    //  * The mirror mistake, listing a handler the path never hits, instead
+    //    fails with "handler function was not executed".
+    //  * A handler that hardcodes its answer and asserts inline, with no
+    //    enqueue/dequeue -> nothing proves the RIGHT dialog fired the RIGHT
+    //    number of times, and a failed inline assert can be swallowed by the
+    //    calling UI operation.
+    [Test]
+    [HandlerFunctions('ConfirmHandler')]
+    procedure PostDocumentConfirmsAndMessages()
+    begin
+        // No Initialize(): a value leaked by an earlier test corrupts this one.
+        RunPostingThatConfirmsAndMessages();
+        // No AssertEmpty(): a missing or extra dialog goes unnoticed.
+    end;
+
+    local procedure RunPostingThatConfirmsAndMessages()
+    begin
+        // Raises a Confirm AND a Message, but only ConfirmHandler is listed:
+        // the Message has nothing to intercept it -> unhandled-UI runtime abort.
+        if Confirm('Post this document?', false) then
+            Message('Posting completed.');
+    end;
+
+    [ConfirmHandler]
+    procedure ConfirmHandler(Question: Text[1024]; var Reply: Boolean)
+    begin
+        // Hardcoded expectation and hardcoded reply. If the wrong dialog fires,
+        // this inline assert may never surface as the test's verdict.
+        Assert.AreEqual('Post this document?', Question, 'Wrong confirm.');
+        Reply := true;
+    end;
+
+    var
+        Assert: Codeunit "Library Assert";
+}