<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 4, 2017, at 2:25 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Jan 4, 2017 at 11:55 AM Pete Cooper via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></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 class=""><br class=""></div><div class=""><div class="">I'd like to understand -- why do you not like it?</div><div class=""><br class=""></div><div class="">On one hand, I dislike it because it is longer to type and read.</div></div></div></div></div></blockquote>Thats all it is TBH. Seems like we should just do "#define EXPECT_EQ(a, b) EXPECT_THAT(a, Eq(b))" or something similar. Or perhaps it just doesn't matter that much.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><div class="">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 class=""> </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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">It is only the EXPECT_* and ASSERT_* bits that gmock provides an alternative for.</div></div></div></div></blockquote>Ah ok, thanks for clarifying.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></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 class=""><br class=""></div><div class="">This is essentially where I am at.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">I'd also be totally willing to have LLVM-specific aliases of:</div><div class=""><br class=""></div><div class="">EXPECT(...) -> EXPECT_THAT(...)</div><div class="">ASSERT(...) -> ASSERT_THAT(...)</div><div class=""><br class=""></div><div class="">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></div></div></blockquote>Yeah, thats totally fine with me.<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">Anyways, this is something of a detail to sort out if we want the matcher functionality.</div></div></div></div></blockquote>Sounds good. Cheers!</div><div><br class=""></div><div>Pete<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br class=""></div><div class="">-Chandler</div></div></div>
</div></blockquote></div><br class=""></body></html>