Skip to Content
3

Is it possible to test ASSERT in ABAP Unit? ​

Nov 28, 2017 at 07:06 AM

197

avatar image

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.

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

3 Answers

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

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

Klaus

Show 1 Share
10 |10000 characters needed characters left 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.

Thanks,
Mike

0
Sandra Rossi Nov 28, 2017 at 07:32 AM
2

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.

Show 2 Share
10 |10000 characters needed characters left characters exceeded

Agree. They don't have to be overly complex to warrant testing. To use my current use case: a method can be called in two ways, each supplying one of two optional parameters, but we would never receive values in both.

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

ASSERT is used here, because it should not happen, and if it does it is not an exception but a programming fault and the calling code should never go to production.

But it would be nice to unit test it, if only to get rid of the red bits in the coverage results :-)

1

I understand. Is it worth testing it, I don't know. Maybe SAP will propose something in the future.

0
Suhas Saha
Nov 28, 2017 at 09:01 AM
-1

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.

Cf. https://help.sap.com/doc/abapdocu_751_index_htm/7.51/en-US/index.htm?file=abenexception_category_guidl.htm

Show 2 Share
10 |10000 characters needed characters left characters exceeded

No, this would not make sense. I'm asserting that the developer didn't do something stupid. If the developer catches exceptions then they would understand the reason and not be passing the parameters incorrectly in first place.

The other part to consider is simplicity. It should never happen, so adding exceptions just adds unnecessary complexity. If it does happen something is desperately wrong - I also see ASSERT as something stronger than an exception.

The example is just an example, and has no real relevance to the question. There many many other ASSERT scenarios, and it would be nice to test at least some of them.

But as we are discussing it, the background to this example is: his 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. Same data passed in different ways depending on who is calling it.

0

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".

0