[lldb-dev] unit testing C++ code in LLDB

Zachary Turner zturner at google.com
Fri Oct 3 10:37:48 PDT 2014


I don't think the unit tests should depend on the python tests.  They
should be self contained.  In other words, the unit tests must be useful to
someone who is compiling without support for embedded python.  I wouldn't
want to have a unit test which is only useful if it's called from Python
which has already done some initial setup.  Still, if you want to avoid
having another entry poitn for convenience, you could expose something from
the public API that allows you to just say "run all the unittests".  But
there shouldn't be any setup in the python.  All the setup necessary to run
a given test should happen in C++.

On Fri, Oct 3, 2014 at 10:23 AM, Sean Callanan <scallanan at apple.com> wrote:

>
> > On Oct 2, 2014, at 9:27 PM, Todd Fiala <tfiala at google.com> wrote:
> >
> > Hey Sean!
> > …
>
> Thanks for the introduction!  It looks like this is definitely in the
> direction of what I want.
>
> > If we want to do collaboration tests (integration tests, etc.), we're
> probably into the "should be in python category", but we might have a few
> low-level multi-class testing scenarios where we might want a different
> gtest/functional, gtest/integration or something similar directory
> structure to handle those.  Would be good to have discussion around that if
> we find a valid use for it.
>
> One thing I would like to be able to do for the expression parser is unit
> test in the context of a stopped process.
> I’m thinking of scenarios where I’d like to test e.g. the Materializer’s
> ability to read in variable data and make correct ValueObjects.
>
> One way to achieve this that comes to mind is to have a hook into the unit
> tests from the Python test suite, so we can set up the program’s state
> appropriately using our normal Python apparatus and then exercise exactly
> the functionality we want.
>
> Once we’ve got that kind of hook, we could just run all unit tests right
> from the Python test suite and avoid having another entry point.
>
> If you want IDE-friendly output, you could have an IDE-level target that
> runs test/dotest.py but singles out the unit tests.
>
> What do you think?
>
> Sean
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141003/85547026/attachment.html>


More information about the lldb-dev mailing list