Feature request: Standardize order of parameters when using CL_ABAP_UNIT_ASSERT

[ConjuringCoffee]

Hi Jörg-Michael, I've got another feature request for you: I'd like to be able to set a standardized order of parameters when using CL_ABAP_UNIT_ASSERT, especially when using method ASSERT_EQUALS.

Bad example:

    cl_abap_unit_assert=>assert_equals( act = lines( lt_table )
                                        exp = 1 ).

    cl_abap_unit_assert=>assert_equals( exp = 'S'
                                        act = lt_table[ 1 ]-type ).

I believe it can be confusing if the order of act and exp changes from call to call. In code reviews I noticed that this caused some accidental mix-ups.

What do you think?

[jmgrassau]

Hi ConjuringCoffee,

completely agree, very nice idea!

It would also be great if we were able to extend this to any method call, sorting parameters in the order defined by the method signature (or, for VALUE constructors, by the order defined by the respective structure); however, that signature or structure definition would usually be "out of sight", so without additional backend calls, we couldn't get it.

Kind regards,
Jörg-Michael

[jmgrassau]

Hi ConjuringCoffee,

thanks again, really like this idea! The new cleanup rule "Standardize assertion parameter order" is now available with version 1.11.0, which was just released!

I identified three "groups" of methods, for which you can configure the order of parameters separately:

In each case, you have (with slightly different parameter names):

I aligned with clean code experts that "expectation first" is the best default in all three cases, despite method signatures currently having "act" before "exp" for the first group.

Everything else (esp. one-liners and the position of closing parenthesis) is kept as is by this rule. The result looks like this:

As you can see from the last option, the rule can also be applied to an (application-specific) assert class CX_…_ASSERT for product code with signatures similar to CL_ABAP_UNIT_ASSERT (cp. rule "Use assert class instead of ASSERT").

Kind regards,
Jörg-Michael