[Gelöst] TestToolkit - Test Codeunit Diverse Fehler

Hallo,

ich wollte mal eine Test Funktion ausprobieren (bin die Schritte hier gefolgt: Walkthrough)

Wenn ich die Test Funktion ausführe, bekomme ich als First Error: "Object of type CodeUnit with ID 131300 could not be found". Codeunit 131300 aber existiert, und auch die Test CU wo die Funktion drin ist meckert nicht (dort ist die CU referenziert). Worran könnte es liegen?

Weiter kam vor dem Ausführen die Meldung dass ich die Sprache auf English (US) umstellen muss, weil "The Tests contain Captions in ENglish (US) and not the current language. If You do not Change the language, test will fail because cannot find text in english US" Welche Captions sind damit gemeint?

Danke

EDIT> Hab die Sprache auf English US umgestellt. Der erste Fehler, Object vom type Codeunit... wird nicht mehr angezeigt.
Jetzt lautet der FirstError: Unhandled UI: Message

cuTest.png

Was kann jetzt falsch sein?

Danke

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Zuletzt geändert von elTorito am 21. September 2018 11:07, insgesamt 1-mal geändert.

So wie es aussieht gibst Du eine MESSAGE aus, um diese MESSAGE zu handeln (wie auch evtl. sämtliche andere MESSAGE's die in der Routine, welch die Test-Codeunit abarbeitet), benötigt die Test-Codeunit eine Funktion mit dem FunctionType::MessageHandler (einen ConfirmHandler hast Du ja schon).

So wie es aussieht gibst Du eine MESSAGE aus, um diese MESSAGE zu handeln (wie auch evtl. sämtliche andere MESSAGE's die in der Routine, welch die Test-Codeunit abarbeitet), benötigt die Test-Codeunit eine Funktion mit dem FunctionType::MessageHandler (einen ConfirmHandler hast Du ja schon).

Tatsache.... Vielen Dank für den Hinweis!
(Hätten die ja mal in dem Walkthrough dabei schreiben können)

Ok. Weiter geht es zum nächsten Problem

Laut Funktion soll der Test annehmen dass die zu vergleichenden Werte Gleich oder Fast Gleich(nearly?) sein sollen:

Code:

Assert.AreNearlyEqual(SalesLine."VAT Base Amount",VATBaseOriginal,LibraryERM.GetAmountRoundingPrecision,''); 

Führe ich den Test aus wird das quittiert mit:
Assert.AreNearlyEqual failed. Expected a difference no greater than <0,01> between expected value <505,58> and actual value <424,86>.

Also scheinbar eine Differenz zwischen den Beträgen nach dem setzen des Häkchen?
(Manuell über RTC scheint alles ok)

Hier mal der Code der TestFunktion:

Code:

[Test] HandlerSampleTest()
//h ttps://docs.microsoft.com/en-us/dynamics-nav/walkthrough--create-a-test-with-confirmation-dialog

// [SCENARIO] When the user chooses "Price Including VAT" and agrees to update sales lines, the VAT Amount must stay nearly the same. 
// [GIVEN] Basic sales document with item 
ItemQty := LibraryRandom.RandInt(100); 

LibrarySales.CreateSalesDocumentWithItem(SalesHeader,SalesLine,SalesHeader."Document Type"::Invoice,'','',ItemQty,'',0D); 
VATBaseOriginal := SalesLine."VAT Base Amount"; 

//[WHEN] The user chooses the "Price Including VAT" field and agrees to update the sales lines (handler) 
SalesHeader.VALIDATE("Prices Including VAT",NOT SalesHeader."Prices Including VAT"); 
SalesHeader.MODIFY(TRUE); 
//[THEN] Updated VAT Base Amount is the same as originally calculated 
SalesLine.FIND; 
Assert.AreNearlyEqual(SalesLine."VAT Base Amount",VATBaseOriginal,LibraryERM.GetAmountRoundingPrecision,''); 

Wo könnte es jetzt dran liegen dass der Test fehlschlägt?

Danke

Testest du gerade auf einer Standard-DB oder eurer eigenen?
Zum Erlernen der Test-Funktionsweise, fange am besten erst mit einer Standard-DB an. Bleibe dort unbedingt beim Standard-Rollencenter, und lasse mal dort die Tests durchlaufen. Du wirst feststellen, dass selbst hier nicht alles fehlerfrei durchlaufen wird. Solche neg. Tests kannst du dann auf deiner eigenen DB ignorieren.

Ergo: nur in Kombination mit einer Standard-DB findest du am ehesten heraus, ob ein Fehler aufgrund eurer Anpassungen (und anderem Rollencenter!) liegt oder nicht. Manchmal muss man beide DB-Tests parallel debuggen, um den Grund herauszufinden ....
Es gibt da noch einiges mehr zu beachten, aber das kann ich in der Kürze der Zeit gar nicht wiedergeben.

Dann muss man einfach den Programmcode in der Funktion AreNearlyEqual anschauen

Dann muss man einfach den Programmcode in der Funktion AreNearlyEqual anschauen

Nein, das wird nicht helfen. Die Fehlermeldung sagte schon aus, was innerhalb der Funktion geprüft wurde. Rein mathematisch.
Die Aufgabe besteht jetzt darin herauszufinden, warum zwei so unterschiedliche Werte überhaupt an AreNearlyEqual übergeben wurden, also wie diese zustande gekommen sind. Darum auch die Standard-DB als Referenz.

Testest du gerade auf einer Standard-DB oder eurer eigenen?
Zum Erlernen der Test-Funktionsweise, fange am besten erst mit einer Standard-DB an. Bleibe dort unbedingt beim Standard-Rollencenter, und lasse mal dort die Tests durchlaufen. Du wirst feststellen, dass selbst hier nicht alles fehlerfrei durchlaufen wird. Solche neg. Tests kannst du dann auf deiner eigenen DB ignorieren.

Datenbank ist eine Standard, allerdings Branchenlösung. Habe da unsere eigene Programmierung noch nicht implementiert.

Ich hab jetzt den gleichen Test mal in der Standard Cronus ohne Branchenlösung laufen lassen.
Dort bekomme ich den Fehler:
The following UI handlers were not executed: MessageHandler

Habe den MessageHandler mal rausgenommen.

Der Messagehandler war (scheinbar) in der Branchen DB nötig , weil nach der Änderung auf Preis Inkl. Mwst noch eine Kreditlimitprüfung statt findet.

Bleibt dann jetzt die Frage zu klären warum der Test in der Branchen DB so unterschiedliche Werte liefert.

Ich werde mal etwas anderes/einfacheres testen Ich kann mir aber auch mal die Vorhandenen Test CUs angucken, da gibt es ja so einige.

Kann man solche Tests auch Debuggen?
Hab grad mal versucht Breakpoints zu setzen, hat aber nicht angeschlagen.

Debugger funktioniert eigentlich ganz normal ....
Vielleicht hast du den Debugger nicht richtig aktiviert oder den Breakpoint an falscher Stelle gesetzt?

Ja. Geht jetzt.
Falsche Session erwischt oder vergessen zu zu starten. Freitag ...
Muss mich noch dran gewöhnen, in 2009 ist der Debugger immer direkt mit gelaufen