How to test public methods for LN

This topic describes how you can test the public layer of the BOL software, before exposing the layer to the outside world.

Introduction

This online manual topic is written for LN product consultants, product architects, software engineers, and test engineers that want to know how to test the public layer of a Business Object.

This manual topic provides a general explanation of the test tool for the public layer and the basic procedure for testing.

The test tool enables you to test the public layer of a Business Object. This test tool simulates the Infor LN Business Adapter software, which calls the public layer in a life situation.

Details on the user interface of the test tool are available in the help text of the BOL Test Tool - Public Layer (tlbct3250m000) session.

For details on how to test the various public methods, refer to To test the public methods at the end of this topic.

The explanation in these related topics is done using the official prototype of the BOL workgroup:

  • Package: tl
  • Module: bct
  • Business Object: 790
  • Name: Order
  • Description: Order Control System
Note

The reader of this topic is assumed to have knowledge of the BOR and the BOL.

When testing the public layer, the protected layer is implicitly tested because the public layer reuses the protected layer.

Procedure

To test a public method, take the following steps:

  1. Start the BOL Test Tool - Public Layer (tlbct3250m000) session. To start this session, on the Tools menu, point to Application Development, and click Business Object Modeling.
  2. Enter the Test ID and Description.
  3. Select the business object and the public method to be tested.
  4. Enter data for the Request argument of the selected method.
  5. Select attributes for the standard List and Show methods (if applicable). The Attribute selection is part of the Request argument.
  6. Define a Filter for the standard List and Show methods (if applicable). The Filter is part of the Request argument.
  7. Run the test.
  8. View the test results.

After the test is completed, you can add the test to the test history to reuse the test later. Refer to History for details.

History

The test tool enables you to store test data. You can use this data to reuse test data that was entered previously (Request argument). In addition, the result data is stored (Response and Result argument).

In addition, the history provides insight into which tests have been run in the past for a particular BOL. The history feature automates regression testing for the basic part.

In the test tool, you can enter an identification number for each test case in the Test ID field. Test ID 0 (zero) is not permitted.

Test cases are registered by user and stored in a company that was set up for BOR-related data. You choose this company in the Initialize Tools Add On (tlcom0200m000) session.

After you start the test tool, the test case with the highest test ID number is automatically loaded.

  • To start a new test case, you must enter a new test ID number. When you enter a new test ID, you must also enter a new description.
  • To reuse a saved test case, zoom on the Test ID field to start the Test History (tlbct3550m000) session and select the desired test ID from the list.
Note

In the test tool BOL Test Tool - Public Layer (tlbct3250m000), you can click Update History, Copy History, or Remove History to add, update, or remove test cases that appear in the list.

Company handling

The test tool deals with various data sets ( companies):

  • Your current company. The Business Object that is tested uses this company. For example, if you test the Create method of the Sales Order Business Object, a new sales order record is inserted in your current company. You can check your current company at the bottom-right corner of the test tool's session window.
[...]
  • The company that contains the test related data. The tl package uses this company to store the test case history. This company is specified in the Initialize Tools Add On (tlcom0200m000) session.
  • The company number that is specified in the routing attributes of the request argument ("site" attribute).

Depending on the event or action requested by the user, the program switches between data sets.

Constraints
  • In the graphical browser for the Request argument, you cannot reload attributes that are deleted from the tree. If you delete one attribute too much, you must restart filling the Request argument from the beginning.
  • In the graphical browser for the Request argument, you cannot delete attributes as a group or range. Attributes must be deleted one by one, which is less user friendly when dealing with many attributes.

Related topics