jingham added a comment. It does look a little weird as a unit test, but to me this is mostly because it would been much simpler to write it as a regular SB API test.
Anyway, I really don't want the details of the text output of lldb commands to become API. Our experience with gdb was that over time as you write more and more tests that scrape text output, you end up not being able to change command output because the burden of fixing up all the tests becomes too onerous. You can use text scraping in the current lldb testsuite. We discourage that for the reasons above, and try to isolate the tests that do so by having lldbutils interfaces to do the explicit scraping. But it is just as easy, and quite often much easier, to examine objects directly in the lldb testsuite, so this mechanism encourages virtue, even though it doesn't enforce it. OTOH adding a test mechanism that explicitly relies only on command output scraping leads us down the path that ended up being a real PITN for the gdb testsuite. So for that reason I am not in favor of going this way. https://reviews.llvm.org/D40616 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
