That sounds like a great idea. It should make a nice half-way between the regular SB tests and the inline tests. The latter are super easy to write, which is nice, but hard to debug - particularly when you have to insert some more error output because the test only fails on a bot or some system you can't get your hands on - which happens more often that you might naively think.
Also, the less we do by hand test by test the cleverer we can be about optimizing test running. Jim > On Jan 22, 2018, at 3:28 AM, Pavel Labath via Phabricator > <revi...@reviews.llvm.org> wrote: > > labath added a comment. > > In https://reviews.llvm.org/D42280#982229, @jingham wrote: > >> I didn't intend to block this patch, just to point out that this was really >> work you shouldn't have had to do, and that as we touch these files we >> should clean them up so next time we don't have to. It will also make the >> test files easier to read. > > > While we're on that topic, I would actually propose going one step further > than `lldbutil.run_to_source_breakpoint`. I would propose creating a new test > class (StandardLaunchTestCase ?) . This class would assume a certain > executable name (a.out), a certain source file name (main.cpp, but this can > be taken from a class property, so it can be overriden to main.mm for objc > tests) and a certain breakpoint string. > > That way, it can do the "build, set breakpoint, launch, validate stop reason" > dance without any user input in the setUp() method, and the test can start > with the process primed and ready and just focus on the thing it's testing > > > Repository: > rL LLVM > > https://reviews.llvm.org/D42280 > > > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
