Skip to Content

Is it possible to test ASSERT in ABAP Unit? ​

I would like to catch assert failures in ABAP Unit tests.

Technically it should be possible, because the ABAP Unit framework does intercept them. We get a message "[The ASSERT condition was violated.]" instead of a dump. Instead, I would like to unit test that the ASSERT fails. Unfortunately I can't find anything in the AU framework to handle it.

I could raise an exception instead of ASSERT, but I think ASSERTS have their place and it would be useful to be able to test these. Ironically, the ASSERT I was trying to test this with had an error in it and wasn't being raised at first, so my testing had real value here.

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Best Answer
    avatar image
    Former Member
    Nov 28, 2017 at 06:24 PM

    Hello Mike,

    if I understand the requirement properly the intend is to validate the use of ASSERT methods in concrete tests for correctness. Well that is tough. ABAP Unit internally uses EVENTS both in the session of the test sandbox executing the test methods as well as in the session of the test driver. As such you can theoretically register to the event but not intercept it. Thus it is virtually impossible to test the use of ASSERT methods within test methods. Besides these EVENTS are an ABAP Unit internal detail and as such referring to them is strongly discouraged.

    The use of the ASSERT statement as mentioned before is no alternative either. It terminates the ABAP runtime and prevents this way any programmatic validation of the behaviour of your tests in the same ABAP session.

    To try tests of test code I would introduce custom asserts. That is you provide a class with your own custom assert logic. For instance in standard test mode delegating to methods of CL_ABAP_UNIT_ASSERT and to execute some extra behaviour for the meta test mode.

    Looking on my personal best practices I use custom asserts to improve readability of tests and failure log. I doubt that using them for the meta tests would yield such qualities for the meta tests. And as readability and thus maintainability is very important to me I won´t go this way for my own tests.

    Do you have only positive tests that ensure the functionality is working properly? If so, yes I know that is not only slightly different, adding negatíve test logic that ensure the functionality fails properly for faulty input might soften up the original problem.

    Hope this helps


    Add comment
    10|10000 characters needed characters exceeded

    • Hello Klaus,

      Thanks for your comprehensive answer, it does explain it.

      I like the idea of a custom assert, kindof like a production version of the CL_ABAP_UNIT_ASSERT, will give that some thought. On the flip side it does add a little overhead, so would probably use standard ASSERTs for the pure sanity check/unrealistic scenarios.

      Re. your question "Do you have only positive tests that ensure the functionality is working properly?". No I am also doing negative tests to ensure it will break when it's supposed to, and this is exactly my reason for wishing to test ASSERT statements. If it takes 30 seconds to write two lines of code to test a validation condition then it's a quick win.


  • Nov 28, 2017 at 07:32 AM

    I use ASSERT only as a kind of documentation, i.e. hint for readability, to say "here it's definitely impossible to have this value different from this one, and I prove it as it never dumped".

    But usually ASSERT is only for easy assertions, not complex ones.

    So, either I use ASSERT in the code for easy assertions and there's no corresponding ABAP UNIT, or I use ABAP Unit for complex assertions and there's no corresponding ASSERT in the code.

    Add comment
    10|10000 characters needed characters exceeded

  • Nov 28, 2017 at 09:01 AM

    Hi Mike,

    METHOD blah.
    ASSERT p1 is initial or p2 is initial.

    i would rather define a dynamic exception & propagate it!

    if it does it is not an exception but a programming fault and the calling code should never go to production.

    This means that this situation can be actually prevented by the caller & therefore the choice of using a dynamic exception.


    Add comment
    10|10000 characters needed characters exceeded

    • this particular case is a private method which can be called from own-developed methods with a Z-datatype or from SAP standard via an SAP interface.

      If it's a private method, then declaring an exception would make less sense! I was assuming that the method is a public one & you wanna check that atleast one of the "optional" param provided by the caller is not initial.

      I also see ASSERT as something stronger than an exception.

      +1 ... IMO assertions should be raised when you reach a totally inconsistent state & further processing is no longer an option. For me assertions are the desperate measures in, "Desparate times call for desperate measures".