How to use I_ProductTP_2 in mock-framework?

[AndreM]

Hi,

i have got a functionality that at some point in time also updates the material master using MODIFY ENTITY ... UPDATE on I_ProductTP_2. 

I want to get that functionality under automated test, but I don't seem to be able to actually mock the data in a way that it can be updated.

This is what I've done:

METHOD class_setup.
 sql_test_environment = cl_osql_test_environment=>create( i_dependency_list = VALUE #( ( 'I_ProductTP_2' ) ) ).
ENDMETHOD.
METHOD my_test.
 TYPES tty_product_ids_wr TYPE STANDARD TABLE OF I_ProductTP_2 WITH DEFAULT KEY.
 sql_test_environment->insert_test_data( i_data = VALUE tty_product_ids_wr( ( Product = '990000000000000001' ) ) ).
 sql_test_environment->insert_test_data( i_data = VALUE tty_product_ids_wr( ( Product = '990000000000000002' ) ) ).
ENDMETHOD.

So If I now SELECT from I_ProductTP_2, then my inserted products are perfectly there, but if I run the following, I get a "404 not found" error:

MODIFY ENTITY I_ProductTP_2
  UPDATE FIELDS ( ProductOldID )
  WITH VALUE #( ( %key-Product       = '990000000000000001'
                  %data-ProductOldID = '990000000000000002' ) )
  FAILED FINAL(failed) ##NEEDED
  REPORTED FINAL(reported) ##NEEDED.

So: what am I doing wrong here? If I try to use the CDS-Test-Environment for I_ProductTP_2 the test crashes because one of the underlying CDSes if I_ProductTP_2 must not be used with the CDS-Test-Environment for some unexplained reason.

To me this looks pretty broken on SAP-side, but maybe I am just missing out something here?

[AndreasGraeber]

Hi Andre,

if you want to use the entity for update you have to CREATE it first.
See an example for creation in https://community.sap.com/t5/technology-q-a/deep-creation-of-product-via-i-producttp-2-does-not-work...

The mixture of sql and cds mocking in AUnit is really tricky.

Have fun

Andreas

[alex_frank]

Hi Andre,

If you use the OSQL Test Environment, you're mocking the CDS View I_ProductTP_2 directly. If you use the CDS Test Environment, you mock the dependencies of CDS View I_ProductTP_2, which is used for testing CDS View I_ProductTP_2 itself.

If you however want to mock the RAP BO I_ProductTP_2 for EML statements, you have to use a RAP BO test double framework. Please see the help on the 2 different possibilities here: https://help.sap.com/docs/abap-cloud/abap-development-tools-user-guide/managing-dependencies-on-rap-...

BR,
Alex

[AndreM]

1. You can't use the CDS Test Environment with I_ProductTP_2 because some of the CDSs it is based upon are not released.
2. What does "test the CDS" mean? To me as "can only use released stuff" what's the actual difference in using the different frameworks? From a data-mocking-framework I expect that it behaves consistently as if I were interacting with the database. CDS Test Environment does that for my own CDSs, SQL Test Environment does not seem to work like that (changes on I_ProductTP_2, which is built upon I_Product, do not affect I_Product and vice-versa)

I have not seen any explanation on this anywhere yet, google was no help neither, so can you point that out somehow?

[alex_frank]

With "test the CDS" I mean that you have developed a new CDS view and want to write a test for the logic in it. For I_ProductTP_2, this would be done by a team responsible for the product master in SAP product engineering. If you create your own CDS view, you perhaps want to use the CDS Test Double Framework to test the behavior of your view.
So in the CDS TDF, you mock the dependent-on components (DOC) of the CDS view. The CDS view is the code under test (CUT). In the OSQL TDF, the database artifact (CDS view, table,...) is the DOC and your code that's using the DOC is the CUT.

https://help.sap.com/docs/abap-cloud/abap-development-tools-user-guide/unit-testing-with-abap-unit and the help nodes below it provide some help with writing tests in ABAP. In the "Dependency Management" node of the tree on the linked page you can explore the the different mocking frameworks.

[AndreM]

Okay, I understand that so far, thankyou.

It feels strange though, that in the CDS test environment the provisioning of data to run your tests upon goes by the type of the underlying database table, which feels pretty contradictory.

Yet what I was actually trying get under test is this (and I need mocked data for that):

I have a more or less complex business logic that amongst other things reads data from I_Product and changes data (somewhere else) through I_ProductTP_2. How am I supposed to do this in a consistent way, especially regarding the fact that EML is very easy to be gotten wrong, so I can't just "mock it away", because in 9 out of 10 cases my test will fail in the EML - testing against some fake thing won't help me there, I'd want to test the EML's result on the mocked data throughout the whole thing. And my expectation would have been that mocking data into, say, I_Product through the SQL-Test-Environment would affect the whole test as if it were written on the DB (so all Entities get the same data etc.) - and CDS-Test-Environment does exactly that, though maybe in a strange way - but well it doesn't. How would I ever get complex logic under test this way? How would I ever know if the data I am writing can be handled correctly by some other code that I may not even have under my control?

[alex_frank]

Writing integration tests without mocks would be an option.

Even if you could double the whole database and provide mocks for the 100+ tables used by RAP BO I_ProductTP_2 and keep them in sync with code changes within the BO, you would still get side effects, like Business Events getting triggered.

[AndreM]

So basically it is not possible to mock standard objects in any good or consistent way? The solution is then to have a whole set of test-number-ranges throughout the system and have all functions remember that some data might be test-data?

[alex_frank]

Mocking some database tables in code that you don't own during a test would not lead to a good or consistent test in my opinion. Likely the test would be flaky and lead to an inconsistent system state due to side effects or later changes in the 3rd party code.

If another application developer would send a test like this to me for review, I would urge them to rewrite it.

[AndreM]

so my (not so satisfying) options for testing effects on standard-BOs are:

1. Mock the DAO so that it is disconnected from DB and accept the risk of my EML being wrong and having to re-program side-effects that I need for my test to succeed
2. Run my tests on real data, accepting hidden side-effects throughout the system and at the same time eating up number ranges throughout my DEV environment, colliding with incomplete code-changes elsewhere in the system and so on

Right?

Hm, not what I had hoped for regarding the provided frameworks.

[alex_frank]

It depends on the exact requirements, but in general, when using EML and writing a unit test for it, I would first go towards mocking the RAP BO. Likely with the Transactional Buffer Double framework (https://help.sap.com/docs/abap-cloud/abap-development-tools-user-guide/transactional-buffer-double-s...) when just doing CRUD operations. Then the inner workings of the RAP BO would not be tested, but at least you would know that your EML itself is valid.

For complex and important processes, a test on a higher level of the testing pyramid, like an integration test with real data, would then be an additional option.