How to test flows involving STARTING NEW TASK?

Question

I'm currently using the Data Access Object pattern with interfaces to replace the database access with in-memory data for unit tests. E.g. method find_product_by_id. the ZCL_XYZ_USER_MEM is used for unit tests / integration tests, the _DB for production.

Now I've the problem that I need to do some stuff in background (STARTING NEW TASK). Here I cannot pass my _MEM with the in memory data. I also cannot wait for async to finish in the test case.

The prod use case is like this:

1. HTTP Call triggers methods A which calls B,C,D
2. Method D starts new task1
3. task1 does stuff and optionally calls method E.

So in the prod flow, method D does not use ON END OF TASK, and task1 does not have the in-memory object.

Question: Is there any way to call method A with _MEM, get that _MEM into the new task, wait for the task to finish and verify the result in _MEM (so I can see that the task1 code and method E did the right thing)?

Answer 1

The prod use case is like this:

1. HTTP Call triggers methods A which calls B,C,D
2. Method D starts new task1
3. task1 does stuff and optionally calls method E.

This is not a unit test anymore. This is testing the integration between the independent units A, B, C, D, task1 and E. So it's an integration test. That means that a unit testing framework like ABAP Unit isn't the right tool for it.

Of course you can (and should) use ABAP Unit to create separate tests for the methods A, B, C, D, task1 and E. Those tests should execute those units in isolation. Which means the tests call them directly, and use mock objects to intercept, confirm and validate the database operations and the method calls they are supposed to do to each other or to SAP standard functionality.

But when it comes to testing the interaction between those methods, then you should use an integration testing framework. Like eCATT, for example, which can be used to test whole business processes and their results using GUI scripting. This test operates on the GUI layer, so it's usually not possible to keep them side-effect free. They are going to create some "real" operations on the system, which leave their traces. When those operations are client-specific, then one option is to start each run of the test suit with a client copy, so you are operating on a client with a pristine set of test data. Another option is to add a "cleanup" stage to each test which undos the operations performed by the test before and bring the test data into a state where the test can be repeated.