> On Oct 2, 2014, at 9:27 PM, Todd Fiala <tfi...@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
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to