<div dir="ltr"><br><br><div class="gmail_quote">On Fri, Mar 13, 2015 at 4:01 PM Jonathan Roelofs <<a href="mailto:jonathan@codesourcery.com">jonathan@codesourcery.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+ddunbar<br>
<br>
On 3/13/15 9:53 AM, <a href="mailto:jingham@apple.com" target="_blank">jingham@apple.com</a> wrote:<br>>>> Depending on how different the different things are.  Compiler tests<br>
>>> tend to have input, output and some machine that converts the input to<br>
>>> the output.  That is one very particular model of testing.  Debugger<br>
>>> tests need to do: get to stage 1, if that succeeded, get to stage 2,<br>
>>> if that succeeded, etc.  Plus there's generally substantial setup code<br>
>>> to get somewhere interesting, so while you are there you generally try<br>
>>> to test a bunch of similar things.  Plus, the tests often have points<br>
>>> where there are several success cases, but each one requires a<br>
>>> different "next action", stepping being the prime example of this.<br>
>>> These are very different models and I don't see that trying to smush<br>
>>> the two together would be a fruitful exercise.<br>
<br>
I think LIT does make the assumption that one "test file" has one "test<br>
result". But this is a place where we could extend LIT a bit. I don't<br>
think it would be very painful.<br>
<br>
For me, this would be very useful for a few of the big libc++abi tests,<br>
like the demangler one, as currently I have to #ifdef out a couple of<br>
the cases that can't possibly work on my platform. It would be much<br>
nicer if that particular test file outputted multiple test results of<br>
which I could XFAIL the ones I know won't ever work. (For anyone who is<br>
curious, the one that comes to mind needs the c99 %a printf format,<br>
which my libc doesn't have. It's a baremetal target, and binary size is<br>
really important).<br>
<br>
How much actual benefit is there in having lots of results per test<br>
case, rather than having them all &&'d together to one result?<br>
<br>
Out of curiosity, does lldb's existing testsuite allow you to run<br>
individual test results in test cases where there are more than one test<br>
result?</blockquote><div><br></div><div> I think I'm not following this line of discussion.  So it's possible you and Jim are talking about different things here.</div><div><br></div><div>If I understand correctly (and maybe I don't), what Jim is saying is that a debugger test might need to do something like:</div><div><br></div><div>1) Set 5 breakpoints</div><div>2) Continue</div><div>3) Depending on which breakpoint gets hit, take one of 5 possible "next" actions.</div><div><br></div><div>But I'm having trouble coming up with an example of why this might be useful.  Jim, can you make this a little more concrete with a specific example of a test that does this, how the test works, and what the different success / failure cases are so we can be sure everyone is on the same page?</div><div><br></div><div>In the case of the libc++ abi tests, I'm not sure what is meant by "multiple results per test case".  Do you mean (for example) you'd like to be able to XFAIL individual run lines based on some condition?  If so, LLDB definitely needs that.  One example which LLDB uses almost everywhere is that of running the same test with dSYM or DWARF debug info.  On Apple platforms, tests generally need to run with both dSYM and DWARF debug info (literally just repeat the same test twice), and on non Apple platforms, only DWARF tests ever need to be run.  So there would need to be a way to express this.</div><div><br></div><div>There are plenty of other one-off examples.  Debuggers have a lot of platform specific code, and the different platforms support different amounts of functionality (especially for things like Android / Windows that are works in progress).  So we frequently have the need to have a single test file which has, say 10 tests in it.  And specific tests can be XFAILed or even disabled individually based on conditions (usually which platform is running the test suite, but not always).</div></div></div>