Checking manual page input
Jalmaraz
667
Like
Share
ReportThe other Test Cinderella: Pages
In the previous post I talk about a very underrated subject, report layout testing. This time I am going to talk about another subject I left aside until a few time ago, input data page testing. But after some issues creating new document tables (header lines and lines with item tracking), I began to think in TestPage. When we want to show anything, it is important the example, I am a strong “Hello world” examples hater. In this case I have a good example: extend item tracking, adding a new document with tracking or adding a new field in Reservation Entry. In this case is interesting you need to test the behavior of manual data input in the Item Tracking Lines Page. You need to check that when you input lot and quantity and close the page the lot is related to the new document or check the new field is saved.
TestPage, TestField and PageModalHandler.
Here we are the links of the resources to test pages:
TestPage, TestField are objects that simulates manual inputs in pages. ModalPageHandler is a handler function that rises when we open a page during the test execution. Step 1 we define a handler function:
[ModalPageHandler]
procedure ItemTrackingLinesHandler(var ItemTrackingLines: TestPage "Item Tracking Lines");
and step 2 in the test function we set the function name as handler:
[Test]
[HandlerFunctions('ItemTrackingLinesHandlerWithNoValidate')]
procedure InputTrackingToDocumentWithValidate()
Setting field values with Value and SetValue. The Validate question and hidden controls.
In fields handlings we have many ways to set the values, setting with equal sign, set property “Value” or use method “SetValue”. Whatever you use, the field Trigger Validate is raised. I didn´t find any detailed documentation about this features to clarify when to use each of these ways.
If you access a hidden control a runtime error will raise. This can be useful to test if field is visible or not.
Example: Test Item tracking
The use case steps:
- Fill a document with item tracking. Usually a new document table we are creating in our App, but In this case I use the existing document Purchase order.
- Call the “OpenItemTrackingLines” of the document line table.
- This function show “Item tracking Lines” page.
- With a handler function I simulate a manual input and close the page.
- The we test that the new line have a related Reserve Line, with the right lot number and quantity. In this example we checked another quantity field to make sure that the Validate is raised.
The code is very simple but powerful. This handle function could be generic to check any document line item tracking input, no matter what document table we are processing:
[ModalPageHandler]
procedure ItemTrackingLinesHandler(var ItemTrackingLines: TestPage "Item Tracking Lines");
begin
ItemTrackingLines."Lot No.".SetValue(GlobalLotNo);
ItemTrackingLines."Quantity (Base)".SetValue(GlobalQty);
ItemTrackingLines.OK().Invoke();
end;
And this is the actual test function. I don´t think further explanations are required.
[Test]
[HandlerFunctions('ItemTrackingLinesHandler')]
procedure InputTrackingToDocument()
var
Item: Record Item;
PurchaseHeader: Record "Purchase Header";
PurchaseLine: Record "Purchase Line";
Location: record Location;
ReservationEntry: Record "Reservation Entry";
begin
//[GIVEN] given
LibraryItemTracking.CreateLotItem(Item);
LibraryWarehouse.CreateLocation(Location);
LibraryPurchase.CreatePurchaseDocumentWithItem(PurchaseHeader, PurchaseLine, PurchaseHeader."Document Type"::Order,
'', Item."No.", 1, Location.Code, WorkDate());
//[WHEN] when
GlobalQty := PurchaseLine.Quantity;
GlobalLotNo := LibraryRandom.RandText(MaxStrLen(GlobalLotNo));
PurchaseLine.OpenItemTrackingLines();
//[THEN] then
PurchaseLine.SetReservationFilters(ReservationEntry);
ReservationEntry.FindFirst();
ReservationEntry.TestField("Qty. to Handle (Base)", PurchaseLine."Quantity (Base)");
ReservationEntry.TestField("Lot No.", GlobalLotNo);
end;
Global variables
We need these global variables for this test code.
var
LibraryItemTracking: Codeunit "Library - Item Tracking";
LibraryPurchase: Codeunit "Library - Purchase";
LibraryWarehouse: Codeunit "Library - Warehouse";
LibraryRandom: Codeunit "Library - Random";
GlobalLotNo: Code[20];
GlobalQty: Decimal;
Usually a global variable is a great mistake. It may cause the kind of very hard to detect and replicate issues, but in test codeunits not so bad. Anyway you are looking for errors and the test code is easier to refract, because you already have the test.
*This post is locked for comments