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