Fork us on GitHub Follow us on Google+ Follow us on Facebook Follow us on Twitter

Opened 13 months ago

Closed 2 months ago

#715 closed enhancement (wontfix)

Pcut requires the use of Yoda comparisons

Reported by: Jiri Svoboda Owned by:
Priority: major Milestone:
Component: helenos/unspecified Version: mainline
Keywords: Cc:
Blocker for: Depends on:
See also:

Description (last modified by 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.

Change History (7)

comment:1 Changed 13 months ago by Jiri Svoboda

Description: modified (diff)

comment:2 Changed 13 months ago by 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.

comment:3 Changed 13 months ago by 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.

comment:4 in reply to:  1 Changed 13 months ago by 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).

comment:5 Changed 2 months ago by Jakub Jermář

Can this be closed as will not fix?

comment:6 Changed 2 months ago by 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.

comment:7 Changed 2 months ago by Jakub Jermář

Resolution: wontfix
Status: newclosed
Note: See TracTickets for help on using tickets.