<div dir="ltr">Alongside this, can we come up with a place in the codebase to put shared matchers?  I almost tried to solve this previously when i wanted to unit test some functions returning llvm::Error and/or llvm::Expected objects.  Because if a function returns an error, you have to consume it before you continue or the unit test asserts.  So this is an example of where you might to have a shared matcher that anyone can use.  It seems like there could be other examples of wanting shared matchers as well, so perhaps it's worth adding a folder somewhere under llvm/Unittests that we can provide some support matchers for commonly used things.</div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 4, 2017 at 2:25 PM Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Jan 4, 2017 at 11:55 AM Pete Cooper via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="gmail_msg" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" 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="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><div class="gmail_msg">I'd like to understand -- why do you not like it?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">On one hand, I dislike it because it is longer to type and read.</div><div class="gmail_msg">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><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"> </div><blockquote class="gmail_quote gmail_msg" 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="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It is only the EXPECT_* and ASSERT_* bits that gmock provides an alternative for.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" 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="gmail_msg"><br class="gmail_msg"></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">This is essentially where I am at.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I'd also be totally willing to have LLVM-specific aliases of:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">EXPECT(...) -> EXPECT_THAT(...)</div><div class="gmail_msg">ASSERT(...) -> ASSERT_THAT(...)</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Anyways, this is something of a detail to sort out if we want the matcher functionality.</div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-Chandler</div></div></div></blockquote></div>