[Lldb-commits] [lldb] r327924 - Modernize a test.
Jim Ingham via lldb-commits
lldb-commits at lists.llvm.org
Mon Mar 19 18:57:28 PDT 2018
So that file you are looking for is "packages/Python/lldbsuite/test/README-testsuite. It would be great to have a fresh pair of eyes look this over and add whatever you would have found useful...
> On Mar 19, 2018, at 6:44 PM, Davide Italiano <dccitaliano at gmail.com> wrote:
> On Mon, Mar 19, 2018 at 6:38 PM, Jim Ingham <jingham at apple.com> wrote:
>> Yes, I should have written this function much earlier. I've been trying to convert over to it every time a tests draws my attention (in this case 'cause I pointed it out for you to copy...)
>> It is the way to make a test in the sample_test/TestSampleTest.py. That seemed the most effective way to draw it to people's attention.
>> We could also document it in the README-testsuite as well, after the line recommending that you use the sample_test, but my experience is that people don't much read that doc?
>> Might also be worth a mention in the Projects doc - convert all relevant tests to use run_to_source_breakpoint...
>> I can't think of another prominent place to put docs for it. Maybe if lldbutil.py had a header that lists the most important routines that module provides, people might run across it there.
>> As a new person coming to the code base, where would you have looked to find this?
> I (but I can't speak for everybody of course :) generally look at
> other tests so having everything converted to the new style would
> That said, having maybe a doc for test best practices & how to debug
> now that we're building a pretty decent infrastructure would help
> At least, if we have it, in the code reviews we can just paste a link
> instead of repeating the same set of facts over and over (and
> eventually enough people will see it that they'll learn :)
That file exists, it is:
but it could certainly use some love. I wonder if moving it into the www directory and linking it on the project page might not make it easier to find?
> I'd mention, among others:
> a) inline tests (IMHO, completely change the way of writing test, much
> more concise and nicer for the "common" case)
> b) Jonas' work on lldb-dotest (for people running CMake build, another
> game changer as you don't have to worry about the location of your
> executables when reproducing issues)
> c) common utilities (like the one you recommended)
> d) how to drop into a python debugger (Adrian taught this to me and I
> need to ask him all the time because I forget)
> I'll add this to my TODO list, unless somebody beats me to the punch
> (as my work queue is an append-only data structure these days).
These all sound great!
More information about the lldb-commits