<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">> Is that something that gtest would support?</span><br><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I think gtest is engineered to support having the test runner piece kick off in multiple scenarios.  I'm using it right now in the mode where gtest itself provides the "main" and kicks off all the test runs, but I suspect we can get our hands dirty and specify which test cases to run and control the run loop for it.  If that's true (which just takes some digging or just more knowledge of gtest than my standard C++-only use-the-gtest-provided-main-loop approach has required), seems like something we could get going.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I am in favor of allowing both those modes fwiw if we're doing more collaboration-style tests as is indicated by the "let python set it up."  For straight unit tests, I'd not want to do that if the setup isn't complicated (canonical example: testing a single class in isolation), but for configuration of a set of classes the way the lldb is going to be using them, definitely so.  It's too easy to misconfigure or get false positives on tests passing when state is configured, and also makes it more brittle to adjust those setups when we really change the way something is configured in lldb-proper.</span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div>-Todd</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 3, 2014 at 11:01 AM, Sean Callanan <span dir="ltr"><<a href="mailto:scallanan@apple.com" target="_blank">scallanan@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Zach,</div><div><br></div><div>I can live with two entry points – one without the Python dependency, one accessible through Python.  As you (and Greg, in the past) suggest, we can have a special public API for running unit tests – probably only in debug builds – and use that API from Python.</div><div><br></div><div>I’m not sure that all internal unit tests should do their setup in C++.  I think it makes the test more fragile – and wastes a lot of the machinery we already have – to write a bunch of process-control logic in C++ when what I actually want to test is something specific in an unrelated class.  LLDB is pretty closely tied to Python – for the test cases I write for the expression parser, I think I’d be willing to mandate that Python be available rather than make setup more challenging.</div><div><br></div><div>So that both use cases can coexist, we can just make sure that both the gtest runner and the SB API have the ability to run a subset of the unit tests; the gtest runner runs all those that don’t require external setup, and the SB API can select the tests that need to run with a specific initial setup.</div><div><br></div><div>Is that something that gtest would support?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Sean</div></font></span><div><div class="h5"><div><br></div><div><blockquote type="cite"><div>On Oct 3, 2014, at 10:37 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:</div><br><div><div dir="ltr">I don't think the unit tests should depend on the python tests.  They should be self contained.  In other words, the unit tests must be useful to someone who is compiling without support for embedded python.  I wouldn't want to have a unit test which is only useful if it's called from Python which has already done some initial setup.  Still, if you want to avoid having another entry poitn for convenience, you could expose something from the public API that allows you to just say "run all the unittests".  But there shouldn't be any setup in the python.  All the setup necessary to run a given test should happen in C++.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 3, 2014 at 10:23 AM, Sean Callanan <span dir="ltr"><<a href="mailto:scallanan@apple.com" target="_blank">scallanan@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Oct 2, 2014, at 9:27 PM, Todd Fiala <<a href="mailto:tfiala@google.com" target="_blank">tfiala@google.com</a>> wrote:<br>
><br>
> Hey Sean!<br>
> …<br>
<br>
Thanks for the introduction!  It looks like this is definitely in the direction of what I want.<br>
<span><br>
> If we want to do collaboration tests (integration tests, etc.), we're probably into the "should be in python category", but we might have a few low-level multi-class testing scenarios where we might want a different gtest/functional, gtest/integration or something similar directory structure to handle those.  Would be good to have discussion around that if we find a valid use for it.<br>
<br>
</span>One thing I would like to be able to do for the expression parser is unit test in the context of a stopped process.<br>
I’m thinking of scenarios where I’d like to test e.g. the Materializer’s ability to read in variable data and make correct ValueObjects.<br>
<br>
One way to achieve this that comes to mind is to have a hook into the unit tests from the Python test suite, so we can set up the program’s state appropriately using our normal Python apparatus and then exercise exactly the functionality we want.<br>
<br>
Once we’ve got that kind of hook, we could just run all unit tests right from the Python test suite and avoid having another entry point.<br>
<br>
If you want IDE-friendly output, you could have an IDE-level target that runs test/dotest.py but singles out the unit tests.<br>
<div><div><br>
What do you think?<br>
<br>
Sean</div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><table cellspacing="0" cellpadding="0" style="color:rgb(136,136,136);font-family:'Times New Roman'"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Todd Fiala |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tfiala@google.com" style="color:rgb(17,85,204)" target="_blank"><span style="background-color:rgb(255,255,204);color:rgb(34,34,34);background-repeat:initial initial">tfiala@google.com</span></a></td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"><br></td></tr></tbody></table><br></div>
</div>