Implementing IF_CONSTRAINT Test-Driven

[former_member262580]

Dear Fellow ABAPers,

currently I am writing a custom ABAP Unit Assertion for comparing two structures for partial equality.

The path of choice is implementing the interface IF_CONSTRAINT, and using the resulting class (comparable to a Hamcrest matcher) in combination with the standard assertion method CL_ABAP_UNIT_ASSERT=>ASSERT_THAT.

I am doing this test-driven, so at this stage I am testing my IF_CONSTRAINT~IS_VALID implementation with two structures with different values and assert the result to be false in my test method.

However, as I am using a CL_ABAP_UNIT_ASSERT=>ASSERT_EQUALS inside my IS_VALID method for the actual value comparison (to easily get the nice Expected/Actual messages in the ABAP Unit result), that intentionally failing ASSERT_EQUALS gets tracked in the test result and makes the actually passing test fail for the ABAP Unit runner (setting the assert level to TOLERABLE just makes the result yellow, not green).

Is there a possibility to make the unit runner ignore the used ASSERT_EQUALS, by calling some test framework methods in the test method?

I want to avoid having to duplicate the code in ASSERT_EQUALS just for the sake of a green test.

Best regards,

Frank.

[former_member262580]

Potential route:

An instance of CL_AUNIT_CLASSTEST_SESSION_RES is listening to the failures that the ASSERT_EQUAL is throwing, and provides a public instance method STOP_LISTENING.

But how can I access the instance from within my test method?

Other approaches?

[former_member183804]

Hello Frank,

you have debugged quite a while I guess. Nevertheless it is not possible to overcome the limitation and also to stay with the API. Please repect the package interfaces and stick to the published API classes. Ever heard of ancient greek jewelery  (p.......s b.x)? Using side effects of implementation details seldomly lead to an happy ending.

Regards,

  Klaus

[former_member183804]

Good Evening Frank,

In general constraints do not depend on cl_Abap_Unit_Assert=>assert_That( ). Therefore it shall be possible to code any unit test for your custom constraint. As you mentioned there exists an important limitation. Using the methods of cl_Abap_Unit_Assert within the implementation of the constraint results in an weird test protocol. There exists no possibility to overcome this limitation.

Hope this helps/clarifies

  Klaus

[former_member183804]

Hello Frank,

for the intended reuse of cl_Abap_Unit_Assert methods in a Custom Assertion I propose to go for ordinary methods. For example one can code some zcl_Custom=>assert_Structure_Equals( ) that makes use of cl_Abap_Unit_Assert methods or some alternative compare logic. Regarding self tests one still needs to avoid calls to ABAP Unit asserts. This can be for example reached by internally fork to different comparison services.

In prinicipial this sounds like a solution also for the initial IF_CONSTRAINT approach. Which is true from the limited view point of self tests. But using ABAP Unit asserts in IF_CONSTRAINT implementation would also mess up the test protocoll for the 'productive' use. Depending on the version of ABAP Unit you may get more than one failure (one for the constraint and one for the assert),

Best Regards

  Klaus

[former_member262580]

Hello Klaus,

thank you for your suggestions. I had feared that there was no easy solution for reusing standard assert methods in an IF_CONSTRAINT.

I saw people subclassing CL_ABAP_UNIT_ASSERT and adding custom assert methods. But I had the impression that implementing IF_CONSTRAINT was the preferred way for reusable custom assertions (beside local adhoc assert methods), to avoid Assertion Roulette (very good book with maaany pages, ).

So you say that the alternatives are either leaving the IF_CONSTRAINT approach and go the less desired route of a ZCL_ABAP_UNIT_ASSERT or drop the usage of the ASSERT_EQUAL method and loosing the nice verbose messages in the Unit Runner result?

Could you please elaborate on your idea on forking to different comparison services?

Do you mean calling something like GDV?

Best regards,

Frank.

[former_member183804]

Hello Frank,

writing reusable assertions with if_Constraint is perfectly fine. As long the implementation does not make use of cl_Abap_Unit_Assert (or cl_Aunit_Assert respectively). If_Constraint implementation are required to give back the test protocoll with method get_Description( ).

In case your intend is to use custom comparison in combination with the protocoll of the assert_Xxx() methods custom verification or custom assertion methods are suitable. For example a custom assertion method may contain a sequence of calls to cl_Abap_Unit_Assert methods. That part is should be the easy one. The difficulty is again to unit test the custom assertion. For example the custom assertion may use an instance of cl_Aunit_Assert which gets replaced with a test double for self testing purposes.

Some may wonder why such an approach is not suitable for the constraint case too. The difference is the ABAP Unit protocoll. The architecture of the assert_That() method - which is used for constraint - does not allow that the constraint raises exceptions but requires that every aspect of the verification is exposed by the signature.

Bis demnächst

  Klaus