Re: [lldb-dev] lldb tests and tear down hooks

2016-01-15 Thread Zachary Turner via lldb-dev
There's no reason a finally block inside each test method wouldn't work, and that's probably the simplest solution. On Fri, Jan 15, 2016 at 12:59 AM Pavel Labath wrote: > On 14 January 2016 at 21:52, Zachary Turner via lldb-dev > wrote: > > So what

Re: [lldb-dev] lldb tests and tear down hooks

2016-01-15 Thread Pavel Labath via lldb-dev
On 14 January 2016 at 21:52, Zachary Turner via lldb-dev wrote: > So what if tests could be *either* a method *or* a nested class. If it's a > nested class, it could provide setUp, tearDown, and run methods. These > setup and teardown methods can do whatever they want

Re: [lldb-dev] lldb tests and tear down hooks

2016-01-14 Thread Zachary Turner via lldb-dev
So this is biting us again, for unrelated reasons. I thought of a potentially interesting solution. Right now each test class has a setUp and tearDown method. This method is called before and after EVERY test method in the class. So you can't put anything in these methods unless it's common to

Re: [lldb-dev] lldb tests and tear down hooks

2015-10-22 Thread Todd Fiala via lldb-dev
(And side note: if you're pushing a "lambda: self.foo()" with no arguments, the lambda is unneeded and you can just push "self.foo" --- that cleanup hook pushed on most tests at the end of the file is a perfect example of an unneeded level of lambda indirection). On Wed, Oct 21, 2015 at 12:04 PM,

Re: [lldb-dev] lldb tests and tear down hooks

2015-10-21 Thread Greg Clayton via lldb-dev
I think it was mostly done to provide an exception safe way to cleanup stuff without having to override TestBase.tearDown(). I am guessing this cleanup happens on TestCase.tearDown() and not after the current test case right? I could see it being used to cleanup after a single test case in

Re: [lldb-dev] lldb tests and tear down hooks

2015-10-21 Thread Pavel Labath via lldb-dev
I think we can remove these, provided there is a way to mimic the functionality they are used for now, which I think shouldn't be hard. Anything which was set up in the setUp() method should be undone in tearDown(). Anything which was set up in the test method, can be undone using a try-finally