Claiming ABAPUnit – Again. Part 3: I slowly get why interfaces are good and how mocking works.

[joachimrees1]

If you follow my activities, you know that I am getting into ABAP Unit, and sometimes I share my learnings and questions.

Those are some recent posts:
https://blogs.sap.com/2021/12/05/claiming-abapunit-again.-a-walktrough-part-1/
https://blogs.sap.com/2021/12/06/claiming-abapunit-again.-part-2-more-tests-some-thoughts-and-adt-is...

So, I kind of know for a long time that one should "program against an interface, not a class", but I never really did.
But recently I started to extract interfaces and see how working with them is.

Now I can share a benefit I experienced:
Of course my parameter class has no public methods to set or clear a parameter. And also, it should not have that (parameters a read from customizing tables).
But my mock parameter class I define in the unit test, can very well have such methods (and I can create another one, whenever needed).
And as the both implement the interface, I can use any of them.

[This is probably a textbook example, so it might be not much news to you - but for me, experiencing this in my own, real work is so much more impressive than reading or hearing about the theoretical concept. I think it really clicked]

In an effort of "don't repeat yourself" I tried putting what I want to tell about my test in comments. So the core of this blog post is this code block:

*There is a check, that the stock passed in has to have certain characteristics,

*e.g. a stock type (cat), that is defined as "available".

*The definition which stock types are "available" (e.g. F1, F2) is done in customizing-tables

*and read by and stored in the parameter object (zifewm_mon_stock_mover_params ), that is passed into

*the stock_mover (code under test = cut).

  METHOD is_not_available_stock_cat.

"[given:]

    mt_mock_data = VALUE #( ( cat = 'B6' ) ).          "Data, simulating a line in /SCWM/MON: it has a certain value for stock type. (all other fields don't matter)

    mref_mock_prameters->clear_stock_cat_available( ). "Make sure that stock type is not in the list of acceptable stock types.



    "create the stock mover, passing in the mock data and the mock parameters object.

    cut = NEW zclewm_mon_stock_mover( it_data = mt_mock_data

                                      iref_parameters = mref_mock_prameters ).



"[when:]

*we can now call the public method that contains the check.

    TRY.

        cut->check_and_move_stock( ).

      CATCH zclewm_cx_input_false .

"[then:]

        "if this check fails, an exception is thrown. This is the expected result, so the test passes: we are done here:

        RETURN. "ok!

    ENDTRY.



    "only if for some reason there was NO exception, we reach this point. This is NOT what we expected. The test failed, so this is what we do:

    cl_abap_unit_assert=>fail( ).

  ENDMETHOD.

Questions / thoughts:

- how does this kind of presentation - code block with comments - work for you?
- how would I test the other way round? -> let the check pass? (Do I even need to test that ?)
- my public method is check_and_move_stock -> do some checks, and if all pass, create a warehouse task. Should that be 2 public methods instead ? ( I have more thoughts on that , but this is probably for another post)

best
Joachim