This is an archive of the discontinued LLVM Phabricator instance.

[dotest] make debug info variant accessible in setUp()
ClosedPublic

Authored by labath on Feb 2 2018, 2:25 AM.

Details

Summary

This changes the way we store the debug info variant to make it
available earlier in the test bringup: instead of it being set by the
test wrapper method, it is set as a *property* of the wrapper method.

This way, we can inspect it as soon as self.testMethodName is
initialized. The retrieval is implemented by a new function
TestBase.getDebugInfo(), and all that's necessary to make it work is to
change self.debug_info into self.getDebugInfo().

While searching for debug_info occurences i noticed that TestLogging is
being replicated for no good reason, so I removed the replication there.

Diff Detail

Repository
rL LLVM

Event Timeline

labath created this revision.Feb 2 2018, 2:25 AM
labath updated this revision to Diff 132557.Feb 2 2018, 2:54 AM

Move getDebugInfo definition to "Base" class (fixes lldb-mi tests).

That looks great, to make sure I understand this correctly, is the following accurate?

If we apply this on top of https://reviews.llvm.org/D42763, and we have

tests/my/testA.py:
  class TestA(Base):
    def setUp(self):
       ...
    def testAone(self):
       ...
    def testAtwo(self):
       ...

and we are testing two variants, "dwo", and "dwarf".

dotest.py will instantiate 4 objects:

Aone_dwo = new TestA { debug_info="dwo" }
Aone_dwarf = new TestA { debug_info="dwo" }
Atwo_dwo = new TestA { debug_info="dwo" }
Atwo_dwarf = new TestA { debug_info="dwarf" }

and schedule

Aone_dwo.setUp()
Aone_dwarf.setUp()
Atwo_dwo.setUp()
Atwo_dwarf.setUp()

and then

Aone_dwo.testAone()
Aone_dwarf.testAone()
Atwo_dwo.testAtwo()
Atwo_dwarf.testAtwo()

Is this accurate, or is there something missing to make it behave this way?

That looks great, to make sure I understand this correctly, is the following accurate?

If we apply this on top of https://reviews.llvm.org/D42763, and we have

tests/my/testA.py:
  class TestA(Base):
    def setUp(self):
       ...
    def testAone(self):
       ...
    def testAtwo(self):
       ...

and we are testing two variants, "dwo", and "dwarf".

dotest.py will instantiate 4 objects:

Aone_dwo = new TestA { debug_info="dwo" }
Aone_dwarf = new TestA { debug_info="dwo" }
Atwo_dwo = new TestA { debug_info="dwo" }
Atwo_dwarf = new TestA { debug_info="dwarf" }

and schedule

Aone_dwo.setUp()
Aone_dwarf.setUp()
Atwo_dwo.setUp()
Atwo_dwarf.setUp()

and then

Aone_dwo.testAone()
Aone_dwarf.testAone()
Atwo_dwo.testAtwo()
Atwo_dwarf.testAtwo()

Is this accurate, or is there something missing to make it behave this way?

Not completely accurate. The steps are the correct, but the order is different. It will be something like

for test in ["testAdwarf", "testAdwo", "testBdwarf", "testBdwo"]:
  A = new TestA(test) # initializes A._testMethodName
  A.setUp() # can access debug info variant through A._testMethodName (a.k.a A.testMethodName)
  getattr(A, test)()
  A.tearDown()

I don't know whether this distinction matters for you right now (?)

aprantl accepted this revision.Feb 2 2018, 11:27 AM

Great. The important thing for me was that a new object is constructed for each permutation of test function / variant.

This revision is now accepted and ready to land.Feb 2 2018, 11:27 AM
This revision was automatically updated to reflect the committed changes.