Ansicht
Dokumentation

CLCERT_CHKEXIT_TEST_UTIL - Hilfsklasse für Unit-Tests von Exits

CLCERT_CHKEXIT_TEST_UTIL - Hilfsklasse für Unit-Tests von Exits

RFUMSV00 - Advance Return for Tax on Sales/Purchases   SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Funktionalität

Diese Klasse unterstützt Unit-Tests von Implementierungen des Check-Exits (Methode IFCERT_AE_CHECK~CHECK) im BC-Deployment-Framework. Grundsätzlich können Check-Exit-Methoden nur innerhalb des Frameworks getestet werden, da sie über ihre Schnittstelle Instanzen des Datenbehandlers und des Nachrichtenbehandlers erhalten, die für sich alleine nicht erzeugt werden können.

Die Exits sollen deshalb über einen Aufruf der Check-for-Deployment- bzw. die Check-for-Synchronize-Methode getestet werden, die ursprünglich für die BC-Design-Time entwickelt wurden. Beide Methoden dienen nur zur Prüfung von Konfigurationsdaten vor dem Deployment; das eigentliche Deployment findet nicht statt, und es werden keine Daten in IMG-Tabellen verändert. Check-for-Deployment und Check-for Synchronize sind in den Methoden CALL_CHECK_FOR_DEPLOY und CALL_CHECK_FOR_SYNCHRONIZE gekapselt.

Die Testdaten müssen als XML-Strings in einer speziellen Struktur übergeben werden. Mit den beiden Konvertierungsmethoden TRANSL_ITAB_TO_SCHEMA_BF_UPD und TRANSL_ITAB_TO_SCHEMA_BF_SYNC können die Testdaten in das passende Format gebracht werden.

Um die Klasse nutzen zu können, muß man die lokale Unit-Test-Klasse von ihr ableiten (s. Beispiel).

Beziehungen

Beispiel

Unit-Test-Klasse zum Testen des Check-Exits. Sie dazu auch die globale Klasse CLCERT_EXITS_COUNTRY.

CLASS lcl_exit_test DEFINITION FOR TESTING  DURATION MEDIUM

                                 RISK LEVEL HARMLESS

               INHERITING FROM clcert_chkexit_test_util.

  PUBLIC SECTION.

  PRIVATE SECTION.

    CLASS-METHODS: class_setup.

*                   class_teardown.

    METHODS:       setup                    FOR TESTING,

                   test_check_for_deploy    FOR TESTING.

* Data declaration using the types CLCERT_CHKEXIT_TEST_UTIL provides:

    CLASS-DATA: gt_xml_test_data      TYPE lt_xml_upd_data_type.

    DATA: gt_msg_expected             TYPE lt_msg_type,

          gs_msg_expected             TYPE ls_msg_type.

ENDCLASS.                    "lcl_exit_test  FOR TESTING DU

CLASS lcl_exit_test IMPLEMENTATION.

  METHOD class_setup.

* Create test data in internal tables. As we want to call the Check-for-Update

* service, we need to separate the content in different tables depending on the

* change status (insertion, update or deletion).

    DATA: lt_country_u TYPE STANDARD TABLE OF scert_country INITIAL SIZE 5,

          lt_country_d TYPE STANDARD TABLE OF scert_country INITIAL SIZE 5,

          ls_country TYPE scert_country.

    DATA: lt_countryt_u TYPE STANDARD TABLE OF scert_countryt INITIAL SIZE 5,

          lt_countryt_d TYPE STANDARD TABLE OF scert_countryt INITIAL SIZE 5,

          ls_countryt TYPE scert_countryt.

    ls_countryt = ls_country-country = 'DEU'.               "#EC NOTEXT

    ls_country-intca = 'DE'.                                "#EC NOTEXT

    ls_country-history = 'Long long time ago'.              "#EC NOTEXT

    ls_countryt-langu = 'DE'.                               "#EC NOTEXT

    ls_countryt-country = 'Deutschland'.                    "#EC NOTEXT

    APPEND ls_countryt TO lt_countryt_u. APPEND ls_country TO lt_country_u.

    CLEAR: ls_country, ls_countryt.

    ls_countryt = ls_country-country = 'GBR'.               "#EC NOTEXT

    ls_country-intca = 'GB'.                                "#EC NOTEXT

    ls_country-history = 'Very long time ago'.              "#EC NOTEXT

    ls_countryt-langu = 'DE'.                               "#EC NOTEXT

    ls_countryt-country = 'Grossbritannien'.                "#EC NOTEXT

    APPEND ls_countryt TO lt_countryt_u. APPEND ls_country TO lt_country_u.

    CLEAR: ls_country, ls_countryt.

* Trying to deletd the following entry shall cause a veto

    ls_countryt = ls_country-country = 'XXX'.               "#EC NOTEXT

    ls_country-intca = 'XX'.                                "#EC NOTEXT

    ls_country-history = 'Not long ago'      .              "#EC NOTEXT

    ls_countryt-langu = 'DE'.                               "#EC NOTEXT

    ls_countryt-country = 'Lummerland'.                     "#EC NOTEXT

    APPEND ls_countryt TO lt_countryt_d. APPEND ls_country TO lt_country_d.

    CLEAR: ls_country, ls_countryt.

* Translate and summarize test data for all tables. A check exit can be

* assigned to more than one IMG table. In this case, the internal table

* GT_XML_TEST_DATA will contain one entry for each IMG table.

    CALL METHOD transl_itab_to_schema_bf_depl

      EXPORTING

        iv_tabname        = 'SCERT_COUNTRY'

*    IT_SOURCE_TAB_INS =

        it_source_tab_upd = lt_country_u

        it_source_tab_del = lt_country_d

      CHANGING

        ct_xml_content    = gt_xml_test_data.

    CALL METHOD transl_itab_to_schema_bf_depl

      EXPORTING

        iv_tabname        = 'SCERT_COUNTRYT'

*    IT_SOURCE_TAB_INS =

        it_source_tab_upd = lt_countryt_u

        it_source_tab_del = lt_countryt_d

      CHANGING

        ct_xml_content    = gt_xml_test_data.

  ENDMETHOD.                    "class_setup

  METHOD setup.

* Set expected messages

    gs_msg_expected-msgty = 'E'.                            "#EC NOTEXT

    gs_msg_expected-msgid = 'SCERT_TEST'.                   "#EC NOTEXT

    gs_msg_expected-msgno = '004'.                          "#EC NOTEXT

*MSGV1

*MSGV2

*MSGV3

*MSGV4

    gs_msg_expected-language = sy-langu.

*SCHEMA_NODE

*ENTRY

*FIELDNAME

    MESSAGE e004(scert_test) INTO gs_msg_expected-text.

*   Veto ausgelöst

    APPEND gs_msg_expected TO gt_msg_expected.

  ENDMETHOD.                    "setup

  METHOD test_check_for_deploy.

    DATA: lt_msg TYPE lt_msg_type,

          lv_rc TYPE sy-subrc.

* Start deployment simulation

    CALL METHOD me->call_check_for_deploy

      EXPORTING

        it_content_to_check = gt_xml_test_data

      IMPORTING

        et_messages         = lt_msg

        ev_returncode       = lv_rc.

* Check result

    DATA: lv_asrt_fail TYPE abap_bool.

    FIELD-SYMBOLS: TYPE ls_msg_type.

* Check return code, shall be equal to '4' when a veto has

* occurred.

    CALL METHOD cl_aunit_assert=>assert_equals

      EXPORTING

        EXP                  = '4'                          "#EC NOTEXT

        act                  = lv_rc

       level                = cl_aunit_assert=>fatal

       quit                 = cl_aunit_assert=>no

*    IGNORE_HASH_SEQUENCE = ABAP_FALSE

      RECEIVING

        assertion_failed     = lv_asrt_fail.

* check message table for expected entry

    lv_asrt_fail = 'X'.                                     "#EC NOTEXT

    LOOP AT lt_msg ASSIGNING .

      CHECK -msgid = gs_msg_expected-msgid

       AND  -msgno = gs_msg_expected-msgno.

      CLEAR lv_asrt_fail.

      EXIT.

    ENDLOOP.

    IF lv_asrt_fail IS NOT INITIAL.

      CALL METHOD cl_aunit_assert=>assert_equals

        EXPORTING

          EXP                  = gt_msg_expected            "#EC NOTEXT

          act                  = lt_msg

          msg         = 'Message table does not contain expected messages'"#EC NOTEXT

         level                = cl_aunit_assert=>fatal

         quit                 = cl_aunit_assert=>method

        RECEIVING

          assertion_failed     = lv_asrt_fail.

    ENDIF.

  ENDMETHOD.                    "test_check_for_deployment

ENDCLASS.                    "lcl_exit_test IMPLEMENTATION

Hinweise

Was ist der Unterschied zwischen den Services 'Check for Deployment' und 'Check for Update'?

'Check for Update' erwartet vom Aufrufer (normalerweise die BC Design-Time) zu jeder gelieferten Tabellenzeile den Änderungsstatus ("einzufügen", "zu ändern" oder "zu löschen"). Der Änderungsstatus wird über den Datenbehandler an die Check-Exit-Routine weitergereicht.

'Check for Synchronize' erhält keinen Änderungsstatus vom Aufrufer. Das Deployment-Framework ermittelt selbst, welche IMG-Tabelleninhalte eingefügt, geändert oder gelöscht werden müssen, um die erhaltenen Daten mit den bestehenden abzugleichen. Der Check-Exit erhält den lokal ermittelten Änderungsstatus ebenfalls, so daß aus dessen Sicht kein unterschied zwischen den beiden Services besteht.

Bei einem Unit-Test ist in der Regel zu empfehlen, den 'Check for Update' Service zu nutzen, da im anderen Fall das Testergebnis von den persistenten IMG-Tabelleninhalten abhängig ist, sofern man nicht in der Setup-Methode Daten verändert.

Weiterführende Informationen






General Material Data   TXBHW - Original Tax Base Amount in Local Currency  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 18748 Date: 20240329 Time: 110844     sap01-206 ( 123 ms )