On Thu, 10/27 15:28, Ademar Reis wrote:
> >
> > That indeed becomes true when we start offering the locking mechanism.
> > Right now, our users simply want/need to do setup that is valid for many
> > (usually all) tests. According to Amador, the lack of a such a
> > mechanism, has led users to write larger tests, when they should really
> > be smaller ones.
>
> So we can offer the contrib plugin without the locking mechanism,
> leaving it to users to decide what to do with it. Documented as a
> non-supported feature.
>
> As we learn more about this use-case, we can expose it as a
> fully-supported API.
Just want to add two cents on how sharing resources across multiple tests can be
useful:
Sometimes a test itself is way quicker than the preparation, and the latter on
the other hand could ususally be common across many tests. Without a mechanism
to reuse a setup across multiple tests cases (at least inside the same test
class), test cases are forced to be combined into one. That is, when a test
script would ideally look like this:
class MyTestCase:
def setUp(self):
self.do_a_complicated_setup()
def test1():
self.a_quick_test();
def test2():
self.another_quick_test();
def test3():
self.yet_another_quick_test();
It would be squashed into one test case like this:
class MyTestCase:
def setUp(self):
self.do_a_complicated_setup()
def testAll():
self.a_quick_test();
self.another_quick_test();
self.yet_another_quick_test();
I think the first way is much cleaner because the function names can be
self-explanatory.
Fam
