<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Jan 4, 2017 at 11:55 AM Pete Cooper via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">  EXPECT_THAT(actual, Eq(expected));</div><div class="gmail_msg">  EXPECT_THAT(actual, Ne(not-expected));</div></div></blockquote></div></div></div></blockquote></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">For the cases where you have containers and other non-trivial objects, I completely agree that this is compelling.  However, for simple cases like string equality I don't like the change from EXPECT_EQ(a, b) to EXPECT_THAT(a, Eq(b)).</div></div></blockquote><div><br></div><div><div>I'd like to understand -- why do you not like it?</div><div><br></div><div>On one hand, I dislike it because it is longer to type and read.</div><div>On the other hand, I like it because it is more consistent and explicit what is being *tested* and what the *expectation* is.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Which brings me to what I guess is my main question.  Are we going to be able to keep using EXPECT_EQ (and others) via gtest?  Or are we going to slowly migrate from gtest to gmock?</div></div></blockquote><div><br></div><div>Note that gmock is a subset of gtest, relies on it, and can't work without it. And all of the TEST(...) stuff is strictly gtest.</div><div><br></div><div>It is only the EXPECT_* and ASSERT_* bits that gmock provides an alternative for.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I don't think you are suggesting phasing out gtest, but at the same time I'm not really sure why we should have both.  It may be easier to move completely to gmock if its more powerful, even if the checks are sometimes more verbose for simple cases.</div></div></blockquote><div><br></div><div>This is essentially where I am at.</div><div><br></div><div>If we didn't need the more expressive expectations in some cases, I would totally stick with EXPECT_EQ and friends for consistency and simplicity. But if the use cases for more rich and powerful matchers in test EXPECT lines is compelling, I have a mild preference for not having two ways of writing EXPECT_* and ASSERT_* lines, even though the simple cases are a bit more typing. The consistency and predictability for me win out, but not by much. =] I don't think its a huge deal either way.</div><div><br></div><div>I'd also be totally willing to have LLVM-specific aliases of:</div><div><br></div><div>EXPECT(...) -> EXPECT_THAT(...)</div><div>ASSERT(...) -> ASSERT_THAT(...)</div><div><br></div><div>Because these are only inside of tests, and LLVM's projects are reasonably self contained, if saving the 5 characters helps folks, I'm OK with it.</div><div><br></div><div>Anyways, this is something of a detail to sort out if we want the matcher functionality.</div><div><br></div><div>-Chandler</div></div></div>