[Lldb-commits] [PATCH] D24591: [LIT] First pass of LLDB LIT support

[Zachary Turner via lldb-commits]

On Wed, Sep 14, 2016 at 4:28 PM Jason Molenda <jmolenda at apple.com> wrote:

> I have to concur with Jim's point -- writing & maintaining the gdb
> testsuite for years, which was based on commands & expected output like
> these lit tests, was a huge drag on everyone's productivity as the debugger
> changed over time.  This style of test looks wonderfully easy to read &
> write & debug, but that's only if you ignore long-term maintainability,
> then you quickly find that it was a huge mistake.  I have nothing against
> lit, this is a very nice way of writing commands & expected output tests,
> but having lived through the consequences of that style testsuite, I
> couldn't imagine making that choice again, especially when we've avoided it
> so far.  It's a bit more work to read & write & debug the SB API testsuites
> that we have today, but it's vastly more maintainable long-term.


Isn't that solvable though by having commands which return single values
instead of large blocks of test, so that you don't have to worry about
pattern matching and formatting issues?  The only reason the SB API solves
this problem is because it allows you to query for specific values instead
of for formatted blocks of text.  If you can query for the same specific
values without the SB API, then the problem still seems to be solved.  It's
just a different API.

I would say it's significantly more work to read, write, and debug the SB
API tests, and I'm speculating that that's in part why there's so few.

Granted I have no familiarity with GDB's test suite, but I can't imagine it
not being possible to solve this.  As long as you can query the debugger
for data about a sufficiently granular state, I don't foresee this problem
being an issue in practice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20160914/619255d2/attachment.html>