topic Re: Unit tests for local class in function group in Application Development and Automation Discussions

Unit tests for local class in function group

adam_krawczyk1 — Thu, 09 Aug 2012 07:37:45 GMT

Hi,

I have problem with running unit tests from local class as I want to test another local class within the function group. There is no program or global class in given function group.

In function group XWOC I have created new includes which contains local classes.

ZXWOC_CLD_PM_ORDER_SAVE - contains local class definition:

CLASS lcl_pm_order_save DEFINITION.

... class details ...

ENDCLASS.

ZXWOC_CLI_PM_ORDER_SAVE - contains local class implementation:

CLASS lcl_pm_order_save IMPLEMENTATION.

... class implementation details ...

ENDCLASS.

So I have one local class lcl_pm_order_save. Now I would like to test it with unit tests and another local class.

I extended ZXWOC_CLD_PM_ORDER_SAVE with new class definition for testing, appended at the end of include testing class definition:

CLASS lcl_test_pm_order_save DEFINITION FOR TESTING.

PUBLIC SECTION.

METHODS: test_local_class_1 FOR TESTING.

ENDCLASS.

Also implementation of test class has been added at the end of include ZXWOC_CLI_PM_ORDER_SAVE:

CLASS lcl_test_pm_order_save IMPLEMENTATION.

METHODtest_local_class_1.

cl_abap_unit_assert=>assert_equals(

exp = 'test example'

act = 'test example'

ENDMETHOD.

ENDCLASS.

Now when I open these includes, or any local class to editor and try to exectue Unit Tests I have message:

Program FUGR XWOC is not known in table TADIR

Message no. SABP_UNIT202

And no tests run. It looks like this is caused because I have no global class in the function group, only my own local classes in includes. Is there a way to execute unit tests and test my local class?

Re: Unit tests for local class in function group

dirk_wittenberg — Thu, 09 Aug 2012 08:00:36 GMT

Hi Adam,

is the function group XWOC a customer-exit?

That might be the reason.

Function groups for customer exits don't have an entry R3TR FUGR ... but R3TR FUGS ... in TADIR.

And for FUGS unit tests are not supported.

One workaround is to convert your local class into a global one. Then you can write the unit tests for the global class.

Regards,

Dirk

Re: Unit tests for local class in function group

adam_krawczyk1 — Thu, 09 Aug 2012 08:08:42 GMT

Hi Dirk,

Yes you are right, the function group is customer exit:

XWOC - Customer Exits Notifications

Thank you for so quick and valid response. That explains everything.

It is only a pity that it is not possible to test local class there and it forces to have global class in place that is actually locally needed. But it is anyhow a solution

Regards,

Adam

Re: Unit tests for local class in function group

dirk_wittenberg — Thu, 09 Aug 2012 10:03:11 GMT

Hi Adam,

yes it's a pity. It's the same with BOR-Objects ( transaction SWO1 ). They also don't support unit tests. Somehow SAP wants to push us towards global classes .

In your case an alternative would be to include the includes containing the class under test also in a separate report which then contains the unit-test classes. The inconvenience would be that the tests always have to be executed in these separate report and not from within the function group.

Regards,

Dirk

Re: Unit tests for local class in function group

adam_krawczyk1 — Thu, 09 Aug 2012 10:53:03 GMT

Hi Dirk,

Yes, you are right with that separate report. That is another alternative and good hint, we only need to keep tests "report runner" separated in another place. I like idea of unit tests in ABAP very much but sometimes it is surprising how many tricks we need to do

Thank you for great support! 🙂

Regards,

Adam

Re: Unit tests for local class in function group

Ruediger_Plantiko — Wed, 15 Aug 2012 09:06:46 GMT

Adam,

It's not so much a pity if you use exits only as hooks for your own code.

This is a good design idea anyway, since

the exit represents the event on which you want to react
the coding in the exit represents the task which you want to perform.

It is good to keep 1) and 2) separated. This makes it easy to couple the task to another event if required.

And delegating code into separate units, extracting methods from it, refactoring it, renaming it so that the name expresses in the best way what it does, organizing it, belongs to our main activities as developers anyway.

Regards,

Rüdiger