I posted this blog back in 2005 in SDN (earlier to SCN) & it is missing now ! Hence I am reposting the same content as this concept is very useful & used widely in ABAP development world.

Introduction – Test Data Container

A Test Data Container (hence its is referred as TDC) is an E-CATT Test Object. It is defined in the test repository. It has the following:
– Technical Attributes – Information about the container like description, package assignment etc.
– Parameters – Name of the variable through which test data is passed to test the ABAP object.
– Variants – Different combinations of the test data/values to be used for parameters

TDC is the container or the place holder for test data. In run time appropriate data is fetched from TDC. User can insert values to TDC any time. No activation is required — only saving. TDC can be moved to different systems in the landscape through transport requests – like any other ABAP object.

Advantages of Using TDC in ABAP Unit Testing:

– Avoids data duplication for different scenarios.
– User can add another set of test data to TDC and run ABAP units without making any changes to test script.
– It is very easy, simple to use & maintain.
– For testing different scenarios by giving different values to importing & exporting variables, user has to write code (ABAP Units) only once as test data resides in TDC.
– Only one TDC is enough to achieve 100% ABAP units – ABAP units for all methods.

Creation of TDC

You could go from SE80 or use Transaction STWBM.
I suggest using transaction SECATT as it is simple and easy.

TA: SECATT

Create TDC by maintaining the package, component & transport request.

Parameter Creation:

Parameters are the names of the importing, exporting variables. By varying the values for input (importing) variables, methods are tested for its validity.

As shown in above snapshot the list of parameters are the importing & exporting variables for one of my methods. Values column represents the default value for that parameter. Parameter reference is the data type for those importing/exporting variables.

Creating Variants:

Variants are the scenarios or test data in this testing process. Each variant should have unique name. Variants along with there corresponding values are extracted from TDC in run time and fed in to table. Variants are combination of parameters with its corresponding values.
At one instance, all the parameters & variants which are necessary for testing that particular method are taken into consideration. To achieve this regular expressions are used. This part is shown below in implementation section of this document.
If naming conventions are followed, it will be easy to extract particular set of variants which is required to test method.

Snapshot of the variants creation is shown below:

TDC Variants

Implementation with Example:

For using TDC, user has to get the instance of TDC class. Steps are shown below how to access TDC. Declaration part is followed by a comment which tells the reason for that data.

DATA: lv_tdc                     TYPE etobj_name VALUE '/ISDT/UDTM_MOVE_DATES',  " Name of TDC
           lr_tdc_ref            TYPE REF TO cl_apl_ecatt_tdc_api, “ API to access TDC
           lt_variants           TYPE etvar_name_tabtype, “ ITAB of variants
           lv_param_name         TYPE etpar_name, “ Parameter name
           lv_variant            TYPE etvar_id, “ Variant name
           lt_variants_res       TYPE match_result_tab. “ ITAB of variants

Above shows the data through which user can access TDC, fetch data from TDC and do lots of operation on specified TDC.
At this moment we have variable of TDC class. So the next step is to create object of that class by passing the name of TDC.

lr_tdc_ref = cl_apl_ecatt_tdc_api=>get_instance (i_testdatacontainer = lv_tdc).

Now, using the TDC object we can do operation on TDC through its predefined API’s.
First operation user will do is to get all data from TDC and fed it into internal table. This can be achieved thorough API ‘get_variant_list’.

lt_variants = lr_tdc_ref->get_variant_list ().

This method loads all the data from TDC into lt_variants table.
At any given time we need only few variants from the lt_variants which is specific to particular method testing, we need to extract required variants from table. This is achieved by regular expression.

Find all occurrences of regex ‘DAY*’ in table lt_variants results lt_variants_res.

Table lt_variants_res holds the index of all required variants (variants name starting from ‘day’) in table lt_variants. This makes important to follow naming convention for variants name according to method name which you are testing. With naming convention we can take required variants from lt_variant.

So the next step is to using these indexes extract corresponding data from main table lt_variants.

DATA: ls_variants_res type match_result. 
Loop at lt_variants_res into ls_variants_res. 
     read table lt_variants into lv_variant index ls_variants_res-line.

After variants extraction from TDC, now we want to take the required parameter from TDC. This is very easy job which is done through one method call.

lv_param_name = 'IV_DATE'.

lr_tdc_ref->get_value (
EXPORTING
I_param_name = lv_param_name
I_variant_name = lv_variant
CHANGING
e_param_value = tlv_date
).

‘IV_DATE’ is the parameter which we are feeding to our main development method (method which we are testing in ABAP Units). Similarly as above mentioned, repeat same for all parameter.
Once we got the value of parameters corresponding to its variants, next thing is to call main method by passing these values.

m_ref->move_date_days (
EXPORTING
iv_date = tlv_date
iv_num_days = tlv_num_days
iv_direction = tlv_direction
IMPORTING
ev_date = lv_date
).

Here, the method “move_date_days” is the actual ABAP development object which I am testing using TDC in ABAP Units.

As shown in above code, values which we got from TDC are fed into main method. Now we want to make sure the result from above method (stored in lv_date) should be equal to value which we got from result parameter in TDC.
This is tested through assert_equals method.

cl_aunit_assert=>assert_equals (
act = lv_date
Exp = tev_date " adapt expected value
msg = 'Testing value Ev_Date'
).

ENDLOOP.

As shown in the above code, comparison is done between actual value (which we got from calling the method move_date_days ) & expected value which we got from the TDC.
If both are same then it iterates in loop and does same operation for different input & output values. If the results are not same it terminates and gives ABAP unit result screen with red mark for that method indicating wrong status.

Conclusion

– TDC is very useful & effective for writing ABAP units.
– TDC can be useful for other purposes also where people need to store data and extract at runtime.
– TDC in ABAP Units helps in achieving 100% test coverage with little efforts.

As a developer/ABAPer, it is recommended to write ABAP units to test your developed ABAP objects. TDC helps in writing ABAP units in a efficient way by separating test data & test script.