Unit testing mockup loader for ABAP
Hi Community !
I’d like to share a tool for unit testing me and my team have developed for our internal usage recently.
The tool is created to simplify data preparation/loading for SAP ABAP unit tests. In one of our projects we had to prepare much tables data for unit tests. For example, a set of content from BKPF, BSEG, BSET tables (FI document). The output to be validated is also often a table or a complex structure.
Data loader
Hard-coding all of that data was not an option – too much to code, difficult to maintain and terrible code readability. So we decided to write a tool which would get the data from TAB delimited .txt files, which, in turn, would be prepared in Excel in a convenient way. Certain objectives were set:
- all the test data should be combined together in one file (zip)
- … and uploaded to SAP – test data should be a part of the dev package (W3MI binary object would fit)
- loading routine should identify the file structure (fields) automatically and verify its compatibility with a target container (structure or table)
- it should also be able to safely skip fields, missing in .txt file, if required (non strict mode) e.g. when processing structures (like FI document) with too many fields, most of which are irrelevant to a specific test.
Test class code would look like this:
...
call method o_ml->load_data " Load test data (structure) from mockup
exporting i_obj = 'TEST1/bkpf'
importing e_container = ls_bkpf.
call method o_ml->load_data " Load test data (table) from mockup
exporting i_obj = 'TEST1/bseg'
i_strict = abap_false
importing e_container = lt_bseg.
...
call method o_test_object->some_processing " Call to the code being tested
exporting i_bkpf = ls_bkpf
it_bseg = lt_bseg
importing e_result = l_result.
assert_equals(...).
...
The first part of the code takes TAB delimited text file bseg.txt in TEST1 directory of ZIP file uploaded as a binary object via SMW0 transaction…
BUKRS BELNR GJAHR BUZEI BSCHL KOART …
1000 10 2015 1 40 S …
1000 10 2015 2 50 S …
… and puts it (with proper ALPHA exits and etc) to an internal table with BSEG line type.
Store/Retrieve
Later another objective was identified: some code is quite difficult to test when it has a select in the middle. Of course, good code design would assume isolation of DB operations from business logic code, but it is not always possible. So we needed to create a way to substitute selects in code to a simple call, which would take the prepared test data instead if test environment was identified. We came up with the solution we called Store. (BTW might nicely co-work with newly announced TEST-SEAM feature).
Test class would prepare/load some data and then “store” it:
...
call method o_ml->store " Store some data with 'BKPF' label
exporting i_name = 'BKPF'
i_data = ls_bkpf. " One line structure
...
… And then “real” code is able to extract it instead of selecting from DB:
...
if some_test_env_indicator = abap_false. " Production environment
" Do DB selects here
else. " Test environment
call method zcl_mockup_loader=>retrieve
exporting i_name = 'BKPF'
importing e_data = me->fi_doc_header
exceptions others = 4.
endif.
if sy-subrc is not initial.
" Data not selected -> do error handling
endif.
...
In case of multiple test cases it can also be convenient to load a number of table records and then filter it based on some key field, available in the working code. This option is also possible:
Test class:
...call method o_ml->store " Store some data with 'BKPF' label
exporting i_name = 'BKPF'
i_tabkey = 'BELNR' " Key field for the stored table
i_data = lt_bkpf. " Table with MANY different documents
...
“Real” code:
...
if some_test_env_indicator = abap_false. " Production environment
" Do DB selects here
else. " Test environment
call method zcl_mockup_loader=>retrieve
exporting i_name = 'BKPF'
i_sift = l_document_number " Filter key from real local variable
importing e_data = me->fi_doc_header " Still a flat structure here
exceptions others = 4.
endif.
if sy-subrc is not initial.
" Data not selected -> error handling
endif.
...
As the final result we can perform completely dynamic unit tests in our projects, covering most of code, including DB select related code without actually accessing the database. Of course, it is not only the mockup loader which ensures that. This requires accurate design of the project code, separating DB selection and processing code. But the mockup loader and “store” functionality makes it more convenient.
Links and contributors
The tools is the result of work of my team including:
The code is freely available at our project page on github – sbcgua/mockup_loader · GitHub
I hope you find it useful 🙂
Alexander Tsybulsky
Hello Alexander,
if I understand it correct, than I think test code in "real" code is a design smell.
http://xunitpatterns.com/Test%20Logic%20in%20Production.html
Why not creating a separate class which retrieve the data? In your unit tests you can replace this class easily with a mock instance of this class. Your mock instance could use your data loader than.
Best regards, Tapio
Hi Tapio,
Thanks for a very interesting link!
Well, generally speaking I agree, that test logic in production is not the best approach. This was my concern as well.
It is not that easy in our case though. Our main product is VAT localization which is being developed for 2+ years by now - quite a big piece of code. We didn't separate selection into separate classes from the beginning and now it would be a big pain. We have 20+ classes with logic, separating db interaction would be potentially rather messy for readability. As you might imagine VAT localization operates with many tables: it's own, SD, MM, FI, some customizing tables and some selects should be done in the middle of a logic call. It would potentially add same 20 classes just for selects (well probably a bit less but still a number).
On the opposite: a) current approach just adds one condition and one line of "retrieve", b) result of retrieve is similar to select (sy-subrc + empty data set if not initialized), c) the data and testenv attribute is initialized in a singleton context instance directly from test classes (and test classes are blocked run in production). So it is reliable enough.
Although in general I agree that there is always space for improvement 🙂
Thanks again for the link !
KR, Alexander
I agree to both of you. In a greenfield implementation you should take care of proper encapsulation and loose coupling of components as well as isolated data base access routines.
As you cannot always ensure that in existing implementations, the test flag is a solution with a small footprint. By the way, there will be an ABAP solution for this as well: ABAP News for Release 7.50 - Test Seams and Test Injections