@@ -56,6 +56,21 @@ public String getExample() {
56
56
return ""
57
57
+ LINE_SEP + "CLASS cl_product_code IMPLEMENTATION."
58
58
+ LINE_SEP + " METHOD use_assert_class."
59
+ + LINE_SEP + " \" Explanation: Using ASSERT in product code is discouraged, because it immediately dumps, even when the code"
60
+ + LINE_SEP + " \" is called from a test. You can therefore only test the 'happy' cases. This is unsatisfactory, because for"
61
+ + LINE_SEP + " \" code to be clean and testable, you should be able to safeguard that assertions work correctly in unhappy cases."
62
+ + LINE_SEP + " "
63
+ + LINE_SEP + " \" The solution is to not use ASSERT in product code, but to rather call a 'productive' assert class cx_XYZ_assert,"
64
+ + LINE_SEP + " \" which has methods just like CL_ABAP_UNIT_ASSERT to check your expectations, but is specific to your solution XYZ."
65
+ + LINE_SEP + " \" With that, even the 'unhappy' cases can be tested, because your tests can catch cx_XYZ_assert exceptions and"
66
+ + LINE_SEP + " \" ensure they are raised when they should."
67
+ + LINE_SEP + " "
68
+ + LINE_SEP + " \" Once you have created such a class (short example see below), this cleanup rule helps to automatically convert"
69
+ + LINE_SEP + " \" existing ASSERT statements into static cx_XYZ_assert=>...( ) calls. Since the exact desired behavior of the"
70
+ + LINE_SEP + " \" cx_XYZ_assert class may depend on your solution, the class name is not fixed, but can be configured above."
71
+ + LINE_SEP + " \" To exclude accidental use of this rule, this cleanup rule is intentionally deactivated at first, and the"
72
+ + LINE_SEP + " \" class cx_assert does not exist, but must first be adjusted to your own implementation."
73
+ + LINE_SEP
59
74
+ LINE_SEP + " ASSERT lo_instance IS BOUND."
60
75
+ LINE_SEP + " ASSERT is_any_structure-component IS NOT BOUND."
61
76
+ LINE_SEP
0 commit comments