Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
ennowulff
Active Contributor
This is the 3rd Chapter of the GLADIUS series:

One: Introducing: GLADIUS – A Test Unit Framework

Two: GLADIUS - The Next Level

Secrets Evolved


In the first two parts I showed how to building up a framework for automated learning and workshops. I showed the basics and a first editor prototype based on the DEMO_GENERIC_PROGRAM. The chief attraction is that there is a master class containing a global test unit class and we can smuggle any other (defined) class for executing the main function.

If you take a look at codefights or codewars website than you will ssee that there are public test cases where you can see the input and the output. But there are also secret or hidden test units where you only can see if they passed or failed. You cannot see the input parameters.

If you may ask why there should be tests that the user does not know about: you can create special test cases in these secret tests which makes the user really think if he thinks that everything is right and then there is a test that proves him wrong. But not why... 😉

Create Secret Tests


I want to show you how we can implement these secret tests in our framework:

The easiest way is to copy the class ZCL_GLDS_DEMO_TEST_UNITS to ZCL_GLDS_DEMO_SECRET_TESTS. You can change the method names and adapt the changes:



The test itself should not give too many hints about the test:
    cl_abap_unit_assert=>assert_equals(
exp = 0
act = mo_class_to_test->test_me( 1 )
msg = 'Secret test 1' ).

To check that the unit tests work, we have to copy the class ZCL_GLDS_DEMO_TEST_MASTER to ZCL_GLDS_DEMO_SECRET_MASTER. You have to change the inheritance of the global test class:
CLASS lcl_test DEFINITION
INHERITING FROM zcl_glds_demo_secret_tests
FOR TESTING
RISK LEVEL HARMLESS
DURATION SHORT.
ENDCLASS.

The secret master class is not necessary. But it makes the tests easier for the one who implements the secret test because he can immediately check them by pressing CTRL-SHIFT-F10.

Adpating The Template


The following solution is the simpliest quick & dirty solution. I just added a new section to the report ZGLDS_DEMO_TEMPLATE for the secret tests_
"* use this source file for your ABAP unit test classes
*UT:CLASS lcl_test DEFINITION
*UT: INHERITING FROM zcl_glds_demo_test_units
*UT: FOR TESTING
*UT: RISK LEVEL HARMLESS
*UT: DURATION SHORT.
*UT:ENDCLASS.

"* use this source file for your SECRET unit test classes
*??:CLASS lcl_secret_test DEFINITION
*??: INHERITING FROM zcl_glds_demo_secret_tests
*??: FOR TESTING
*??: RISK LEVEL HARMLESS
*??: DURATION SHORT.
*??:ENDCLASS.

At least the complete template report could easily be created without having the template beacuse all you need to know is the name of the interface, the name of the test units class and the name of the secret tests.

In this solution I decided to have the report and de-comment the lines I need for executing the unit tests or the secret tests.

Checking The Solution


Up to now the report checks the test units and displays the standard screen for presenting the results.



If we did this with the secret tests then the user could easily click on the failed tests and look into the source code of the secret test unit to find out which parameters are used. To avoid this, we have to pick the main information from the test runner result which is not that easy...

the following code find out if there are secret tests that failed and which:
DATA(fails) = lines( task_result_casted->f_task_data-alerts_by_indicies ).
LOOP AT task_result_casted->f_task_data-alerts_by_indicies INTO DATA(alerts).
LOOP AT alerts-alerts INTO DATA(alerts_detail).
LOOP AT alerts_detail-header-params INTO DATA(param).
APPEND param TO lt_secret_tests_failed.
ENDLOOP.
ENDLOOP.
ENDLOOP.
IF fails = 0.
MESSAGE 'Great! All secret tests passed!!' TYPE 'I'.
ELSE.

LOOP AT lt_secret_tests_failed INTO param.
CASE sy-tabix.
WHEN 1. DATA(textline1) = param.
WHEN 2. DATA(textline2) = param.
WHEN 3. DATA(textline3) = param.
WHEN OTHERS.
EXIT.
ENDCASE.
ENDLOOP.

CALL FUNCTION 'POPUP_TO_DISPLAY_TEXT_LO'
EXPORTING
titel = |There are { fails } secret tests failed!|
textline1 = textline1
textline2 = textline2
textline3 = textline3
start_column = 15
start_row = 6.

ENDIF.

The code is very stupid and not very good. But it finds out the number of failed tests and the name of them.



I think here I should find out a much better solution which displays the results in an ALV grid. Also there should be an information abaout the passed tests. But as mentioned somewhere in my last posts the test runner only returns information about failed tests.

If there is someone anywhere who has an idea to adapt the runner I will be glad to hear! 😉

Code Arena 2.0


In this step I slightly adjusted the display of the screen using splitters.


Look-Out


The standard result of the test units is very helpful. If I can interprete the returned data to displaying the results of the secret tests then I also can display the normal test units in a different way. For my purpose the user only needs to know the following about each unit test:

  • name

  • description

  • given input

  • expected output

  • result


to be continued...