Dokumentation zur Testautomatisierung und Beispiele finden
Bevor Sie Ihre Business Central-Anwendung freigeben, sollten Sie die Funktionalität testen, um sicherzustellen, dass sie wie erwartet funktioniert. Testen ist ein iterativer Prozess. Es ist wichtig, wiederholbare Tests zu erstellen, und es ist hilfreich, Tests zu erstellen, die automatisiert werden können. In dieser Lerneinheit werden die Funktionen in Business Central beschrieben, mit denen Sie die Geschäftslogik in Ihrer Anwendung testen können. Zudem bietet sie einige bewährte Methoden zum Testen.
Dynamics 365 Business Central enthält die folgenden Funktionen, mit denen Sie Ihre Anwendung testen können.
Testen von bewährten Methoden
Wir empfehlen die folgenden bewährten Methoden für das Entwerfen Ihrer Anwendungstests.
Der Testcode sollte vom zu testenden Code getrennt gehalten werden. Auf diese Weise können Sie den getesteten Code für eine Produktionsumgebung freigeben, ohne den Testcode freizugeben.
Testcode sollte testen, ob der getestete Code sowohl unter erfolgreichen als auch unter fehlgeschlagenen Bedingungen wie beabsichtigt funktioniert. Diese werden als positive und negative Tests bezeichnet. Die positiven Tests bestätigen, dass der getestete Code unter erfolgreichen Bedingungen wie beabsichtigt funktioniert. Die negativen Tests bestätigen, dass der getestete Code unter fehlgeschlagenen Bedingungen wie beabsichtigt funktioniert.
Bei positiven Tests sollte die Testmethode die Ergebnisse von Anwendungsaufrufen validieren, z. B. Rückgabewerte, Statusänderungen oder Datenbanktransaktionen.
Bei negativen Tests sollte die Testmethode überprüfen, ob die beabsichtigten Fehler auftreten, Fehlermeldungen angezeigt werden und die Daten die erwarteten Werte aufweisen.
Automatisierte Tests sollten keine Benutzereingriffe erfordern.
Tests sollten das System in demselben bekannten Zustand wie zu Beginn des Tests belassen, damit Sie den Test oder andere Tests in beliebiger Reihenfolge erneut ausführen und immer in demselben Zustand starten können.
Die Testausführung und Berichterstellung sollte schnell sein und sich in das Testverwaltungssystem integrieren lassen, damit die Tests als Einchecktests oder andere Build-Überprüfungstests verwendet werden können, die normalerweise auf unbeaufsichtigten Servern ausgeführt werden.
Erstellen Sie Testmethoden, die demselben Muster folgen.
Initialisieren und richten Sie die Bedingungen für den Test ein.
Rufen Sie die Geschäftslogik auf, die Sie testen möchten.
Überprüfen Sie, ob die Geschäftslogik wie erwartet ausgeführt wurde.
Verwenden Sie fest codierte Werte in Tests nur, wenn Sie sie wirklich benötigen. Verwenden Sie für alle anderen Daten zufällige Daten. Zum Beispiel möchten Sie das Feld Ext. Belegnr. erforderlich in der Tabelle „Kreditoren und Einkauf Einrichtung“ testen. Dazu müssen Sie eine typische Einkaufsrechnung erstellen und buchen. Die typische Einkaufsrechnungszeile gibt einen Betrag an. Bei den meisten Tests spielt es keine Rolle, um welche Menge es sich handelt. Zur Inspiration können Sie die Methode GenerateRandomCode in den Tests verwenden, die im Ordner TestToolkit auf dem Business Central-Produktmedium enthalten sind.
Beispiel für Anwendungstests: Testen von Einkaufsrechnungsrabatten
Bevor Sie eine benutzerdefinierte Dynamics 365 Business Central-Anwendung auf eine Produktionsumgebung freigeben, müssen Sie die Anwendung testen. Diese exemplarische Vorgehensweise zeigt, wie Sie die Test-Codeunits und Testbibliotheken zum Testen einer Anwendung verwenden.
Sie haben die Codeunit 70, „Purch-Calc.Discount“, geändert. Dies ist eine Codeunit in der Datenbank von CRONUS International Ltd. Sie möchten die Funktionalität der angepassten Codeunits testen, bevor Sie die angepasste Anwendung zum Verkauf anbieten. Sie erstellen eine neue Test-Codeunits mit neuen Testmethoden, um die „Purch-Calc.Discount“-Codeunits zu testen. Während der Entwicklung verwenden Sie die Anwendungstestbibliotheken, um einen Test mit weniger Codezeilen zu schreiben.
Wenn Sie dieses Beispiel vervollständigen möchten, benötigen Sie:
Dynamics 365 Business Central mit einer Entwicklerlizenz
Das Demo-Datenunternehmen CRONUS International Ltd
Das importierte Test Toolkit
Zufällige Demo-/Testdaten
Sie können die Codeunit Library – Random verwenden, um Zufallsdaten für Ihre Anwendungstests zu erstellen. Verwenden Sie fest codierte Werte in Tests nur, wenn Sie sie wirklich benötigen. Verwenden Sie für alle anderen Daten zufällige Daten.
Weitere Informationen finden Sie unter Zufällige Testdaten.
Derzeit stehen diese Testbibliotheken in Business Central Saas nicht zur Verfügung. Sie können in Business Central lokal und in Docker-Containern installiert werden.
Unter Unterstützung und Einschränkungen für Umgebungstests finden Sie weitere Informationen.
Aufgabe 1: Die Test-Codeunit und ‑methode erstellen
Erstellen Sie eine neue Codeunit und geben Sie an, dass es sich um eine Test-Codeunit handelt.
Definieren Sie das Szenario, das Sie überprüfen möchten, und fügen Sie eine Testmethode zum Testen der Purch-Calc.Discount-Funktionalität hinzu. Standardmäßig handelt es sich bei Test-Codeunits um Testmethoden, sofern Sie nichts anderes angeben.
In diesem Beispiel besteht der Name der Testmethode aus der getesteten Funktionalität Berechnung des Einkaufsrechnungsrabatts und relevante Parameter, die das Testergebnis beeinflussen. Wir empfehlen, dass Sie dieses Namensmuster auch für Ihre Testmethoden befolgen. In unserem Beispiel werden die folgenden Parameter vorgestellt.
PInv für das getestete Dokument, Einkaufsrechnungen. Sie können denselben Test auf Einkaufsbestellungen oder Einkaufsgutschriften anwenden. Wir empfehlen außerdem, dass Sie Testreihen für den Verkaufsbereich gespiegelt haben.
Oberhalb. Es ist eine gute Praxis, Tests für positive und negative Szenarien durchzuführen. In diesem Test möchte Isaac überprüfen, ob Rabatte wirksam werden, wenn der Belegbetrag über einem Mindestbetrag liegt. Der Betrag im Beleg kann jedoch auch kleiner oder gleich dem Mindestbetrag sein.
Ein Entwickler definiert zuerst das Testszenario [SZENARIO], dann detailliert er es mit der Notation Given-When-Then. Schließlich fügt er den AL-Code hinzu. Der Code in dieser Testmethode bereitet die Testdaten vor, indem ein zufälliger Rabattprozentsatz, ein Mindestbetrag und ein Dokumentbetrag festgelegt werden. Anschließend wird ein Kaufbeleg mit einer Zeile erstellt und der Codeunit Purch-Calc.Discount ausgeführt, die den zu testenden Code enthält. Schließlich werden die Ergebnisse der Ausführung der Codeunit Purch-Calc.Discount überprüft und ein Fehler ausgelöst, wenn die Ergebnisse nicht wie erwartet sind.
In dieser Test-codeunit können Sie zusätzliche Testmethoden erstellen, um andere Aspekte von Kreditorenrabatten zu testen. Diese Testmethoden umfassen negative Tests, die bestätigen, dass der getestete Code unter fehlgeschlagenen Bedingungen wie beabsichtigt funktioniert.
Aufgabe 2: Eine Hilfsmethode erstellen
Die nächste Aufgabe besteht darin, eine Hilfsmethode zu erstellen, die Daten für den Test generiert.
Die Hilfsmethode kann wiederverwendet werden, wenn Sie die Testabdeckung erweitern möchten.
Der Code in der Hilfsmethode bereitet Daten für den Test vor, indem ein neuer Kreditor erstellt, der Rechnungsrabatt eingerichtet und ein Einkaufsbeleg mit einem Artikel erstellt wird. Da diese Hilfsmethode nicht spezifisch für den Test selbst ist, können Sie sie für ähnliche Tests wiederverwenden. Sie können es beispielsweise mit anderen Parametern aufrufen und eine Einkaufsgutschrift erstellen, einen %-Rabatt einrichten oder einen Beleg erstellen, bei dem der Gesamtbetrag unter dem auf dem in der Tabelle „Kreditorenrechnungsrabatt“ angegebenen Mindestbetrag liegt.
Dieser Testcode garantiert nicht, dass der Status der Datenbank nach dem Ausführen des Tests mit dem Status der Datenbank vor dem Ausführen des Tests übereinstimmt.
codeunit 50111 "ERM Vendor Discount"
{
// Specifies the codeunit to be a test codeunit
Subtype = Test;
trigger OnRun()
begin
end;
// Makes the method a test method
[Test]
// Adds the test logic to the test method
procedure PurchInvDiscCalculationPInvAbove()
var
PurchLine: Record "Purchase Line";
MinAmount: Decimal;
DocAmount: Decimal;
DiscountPct: Decimal;
PurchCalcDisc: Codeunit "Purch.-Calc.Discount";
begin
// [SCENARIO] "Inv. Discount Amount" should be calculated on Purchase Invoice (in LCY), where Invoice amount is
// above the minimal amount required for invoice discount calculation.
// [GIVEN] Vendor with invoice discount percentage "D" for minimal amount "A" in LCY
// [GIVEN] Create purchase invoice with one line and amount >"A"
DiscountPct := RandomNumberGenerator.RandDec(100, 5);
MinAmount := RandomNumberGenerator.RandDec(1000, 2);
DocAmount := MinAmount + RandomNumberGenerator.RandDec(100, 2);
CreatePurchDocument(PurchLine, PurchLine."Document Type"::Invoice, DocAmount, MinAmount, DiscountPct);
// [WHEN] Calculate invoice discount for purchase document (line)
PurchCalcDisc.RUN(PurchLine);
// [THEN] "Inv. Discount Amount" = Amount "A" * discount "D" / 100
PurchLine.FIND;
Assert.AreEqual(ROUND(PurchLine."Line Amount" * DiscountPct / 100), PurchLine."Inv. Discount Amount", PurchInvDiscErr);
end;
// Creates the test helper method
local procedure CreatePurchDocument(var PurchLine: Record "Purchase Line"; DocumentType: Option; DocAmount: Decimal; MinAmount: Decimal; DiscountPct: Decimal)
var
VendorInvoiceDisc: Record "Vendor Invoice Disc.";
PurchaseHeader: Record "Purchase Header";
VendorNo: Code[30];
begin
// Create vendor
VendorNo := LibraryPurchase.CreateVendorNo;
// Create vendor invoice discount
VendorInvoiceDisc.INIT;
VendorInvoiceDisc.Code := VendorNo;
VendorInvoiceDisc.VALIDATE("Currency Code", '');
VendorInvoiceDisc.VALIDATE("Minimum Amount", MinAmount);
VendorInvoiceDisc.VALIDATE("Discount %", DiscountPct);
VendorInvoiceDisc.INSERT(TRUE);
// Create purchase line
LibraryPurchase.CreatePurchaseDocumentWithItem(PurchaseHeader, Purchline, DocumentType, VendorNo, '', 1, '', 0D);
PurchLine.VALIDATE("Direct Unit Cost", DocAmount);
PurchLine.MODIFY(TRUE);
end;
var
RandomNumberGenerator: Codeunit "Library - Random";
LibraryPurchase: Codeunit "Library - Purchase";
Assert: Codeunit Assert;
myInt: Integer;
PurchInvDiscErr: TextConst ENU = 'The Purchase Invoice Discount Amount was not calculated correctly.';
}