My two cents: (1) I almost always need to read the test to understand/debug a test failure.
(2) As long as the intent of the test is clear, I'm not picky about whether clarifying comments take the form of C++ comments or explanatory EXPECT messages. One thing I would be opposed to is adding explanatory EXPECT messages in an indiscriminate way; IMO that just adds redundancy and violates DRY (most test expectations are pretty self-explanatory). Neil On Mon, May 8, 2017 at 8:24 AM, James Peach <jor...@gmail.com> wrote: > >> On May 1, 2017, at 4:28 PM, Benjamin Mahler <bmah...@apache.org> wrote: >> >> Do you have some examples? > > I think that this: > > EXPECT_EQ(Bytes(512u), BasicBlocks(Bytes(128)).bytes()) > << "a partial block should round up"; > > is a strict superset of this: > > // A partial block should round up. > EXPECT_EQ(Bytes(512u), BasicBlocks(Bytes(128)).bytes()) > > The former is preferable since the person triaging test failures gets the > immediate context of what the expectation is doing. This is valuable even if > you might also find you need to check the source. > >> >> Thinking through my own experience debugging tests, I tend to only get >> value out of EXPECT messages when they are providing information that I >> can't get access to from the line number / actual vs expected printing. >> (e.g. the value of a variable). If the EXPECT message is simply explaining >> what the test is doing, then I tend to ignore it and read the test instead, >> so it would be helpful to discuss some examples to get a better sense. :) >> >> On Sat, Apr 29, 2017 at 10:02 AM, James Peach <jor...@gmail.com> wrote: >> >>> Hi all, >>> >>> In a couple of reviews, I've been asked to avoid emitting explanatory >>> messages from the EXPECT() macro. The rationale for this is that tests >>> usually use comments. However, I think that emitting the reason for a >>> failed expectation into the test log is pretty helpful and we should do it >>> more often. >>> >>> What do people think about explicitly allowing (or even encouraging) this? >>> ie. EXPECT(...) << "some explanation goes here" >>> >>> J >