On 6 April 2016 at 06:23, Todd Fiala <todd.fi...@gmail.com> wrote:
> Okay, thanks all.
>
> FWIW I am running them on the OS X side.  I haven't seen any stability
> problems yet.  I'd also expect them to be very stable, much more like a
> compiler test, since there are far fewer parts in a small-scoped C++ unit
> test (vs., say, our Python tests which are end-to-end and have many moving
> parts).
I've been running them locally, and I haven't noticed any flakyness.
It should be also be much easier to remove it, if we find any, because
of the smaller scope and number of tests.


>
> We've talked about it a bit over here, which I think you're alluding to,
> which is how do we handle them assuming they were treated like any other
> test (i.e. revert or fix fast if they break).  That implies we need to run
> them, which means we should make that easy.  (Particularly easy to not
> forget).  On the OS X side we currently have a target and scheme that will
> build and run them, but it's a separate target.  I haven't done anything on
> the Linux side to make that run, although plugging it into the test targets
> shouldn't be hard.
In cmake, you can run these tests with the check-lldb-unit target. I
like the idea of being able to run both, but I think we should also
keep the option of running them separately. How about:
check-lldb: runs unit and python tests
check-lldb-unit: runs unit tests only
check-lldb-XXX: runs only python tests (for some value of XXX)

>
> I don't think the gtests replace the purpose of our Python tests, but I
> think there's a wide-open place for them, particularly when initially
> testing new classes or hard-to-expose places that would be overly cumbersome
> to test (and therefore don't get tested).
+1
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to