Pcut requires the use of Yoda comparisons

[Jiri Svoboda]

PCUT assertion macros that test for equality require the use of Yoda comaprisons, essentially:

PCUT_ASSERT_[INT_]EQUALS(expected, actual)

while if writing tests manually with == operator one would typically write

assert(actual == expected);

e.g.

assert(rc == EOK)

vs.

PCUT_ASSERT_ERRNO_VAL(EOK, rc)
PCUT_ASSERT_INT_EQUALS(0, list_count(xyz))

This is, at least for me, something very unnatural that I have to keep thinking about when writing tests, consuming precious mental energy.

[Vojtech Horky]

PCUT_ASSERT_INT_EQUALS(0, list_count(xyz))

The reason for this approach is that it gives you more information on failure. Plain assertion tells you about the failure and the expression that failed. This gives you also the actual numbers which could help you narrowing down the issue. You can always use PCUT_ASSERT_TRUE if you think this extra information is not needed.

[Jiri Svoboda]

Maybe I did not make myself clear.

in normal C code a Yoda comparison is:

EOK == rc

wile a normal comparison is:

rc == EOK

for PCUT a Yoda comparison is
PCUT_ASSERT_INT_EQUALS(EOK, rc)

while a normal comparison would be
PCUT_ASSERT_INT_EQUALS(rc, EOK)

Since we prefer to avoid Yoda comparison in regular code (with X == Y), we shouldn't use it with PCUT comparisons (X, Y) either.

[Vojtech Horky]

Replying to Jiri Svoboda:

for PCUT a Yoda comparison is PCUT_ASSERT_INT_EQUALS(EOK, rc)

while a normal comparison would be PCUT_ASSERT_INT_EQUALS(rc, EOK)

Okay, sorry for the misunderstanding. I took ​JUnit.assertEquals as the starting point when designing the API and there the expected value is the first one. For me, the reasoning is that when scrolling through the code, the expected value can be immediately recognized as the first argument (while the actual value can be a longer expression).

[Jakub Jermář]

Can this be closed as will not fix?

[Vojtech Horky]

Can this be closed as will not fix?

I think so. I am not planning to change the ordering in PCUT_ASSERT_*_EQUALS functions. The non-Yoda comparison will be probably part of the new API inspired by ​JUnit's assertThat. I have committed a work-in-progress version to PCUT ​here.