<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></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 Sep 20, 2017, at 11:25 AM, Zachary Turner <<a href="mailto:zturner@google.com" class="">zturner@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Wed, Sep 20, 2017 at 11:14 AM Jim Ingham <<a href="mailto:jingham@apple.com" class="">jingham@apple.com</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=""><div class=""><br class=""></div><div class="">The amount of test coverage lldb has at present has much more to do with the very aggressive schedules lldb has been driven by since its inception than any difficulties with writing tests IMHBSEO. </div></div></blockquote><div class=""><br class=""></div><div class="">This probably applies to the folks at Apple, but I think there's a large disconnect between what you guys experience and what the rest of the LLVM community (and external contributors) experience. </div><div class=""><br class=""></div><div class="">I think this is the opposite of true for everyone else. I've heard it time and time again from long-time LLVM developers as well as would-be contributors.</div></div></div>
</div></blockquote><br class=""></div><div><br class=""></div><div>W.r.t. external contributors writing tests, I think the barrier is one of education not difficulty. Yeah, okay you gotta learn a little Python but I don’t think e is a significant barrier to serious developers, and the alternative would be to figure out how to do the same thing with the lldb_private API’s - which is always going to be harder than the SB API’s - or with some DSL we invent which is unlikely to be that much more straightforward, and which unlike learning the SB API’s will benefit you in the rest of your life as a developer not at all.</div><div><br class=""></div><div>When I explain how to write tests to folks I get more of enthusiasm for an opportunity to get familiar with a practical programmatic interface to the debugger than complaint about the difficulty of writing the test. Admittedly, that’s in part because that’s how I pitch it. But in the same vein, there might be some bias in your impressions if I’m right in imagining that someone coming to ask you how to write a Python test gets more of an earful about how this testing methodology sucks than helpful advice on how to write one! </div><div><br class=""></div><div>Anyway, up till about 6 months ago there was no good template for writing new tests. That was because most of us working on lldb already knew how to write tests. I fixed that by adding the sample test templates a little while ago. If you can think of a way to make these easier to use, please do so. But in my experience folks who haven’t written tests have been able to grab one or the other of them and get a test done pretty easily. The other barrier is learning how to read a test failure. That isn’t hard but the test output is noisy and its easy to overlook the part of the output that tells you directly where to look for the failure. I have it on my list of tasks to write up a description of this process but I have many things on my list of tasks. If somebody else wants to add their experiences to the testing README, please do!</div><div><br class=""></div><div>Jim</div><div><br class=""></div></body></html>