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 if tests could be *either* a method *or* a nes
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 specific to the
> individua
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
(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,
Well you can see them getting added via self.addTearDownHook(), so that
means they're called through an instance. Specifically, it happens in
Base.tearDown(self), so it's basically identical (in concept) to if the
relevant handlers were called in the implementation of MyTest.tearDown(),
but differ
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 case
Yea, that's what I think too. I think this mechanism was probably invented
to just to save some code and promote reusability, but in practice leads to
these kinds of problems.
On Wed, Oct 21, 2015 at 2:07 AM Pavel Labath wrote:
> I think we can remove these, provided there is a way to mimic the
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 blo
