I'm having trouble trying to come up with a elegant solution for this situation.
Let's say I have a unittest in Python that will test several elements from an iterable. Since this iterable is costly to build in memory, I want to build it only once trough the setUpClass method. Then, in each test, I want to sequentially pass each element in the iterable to the test, which I can to using the context manager and the subTest method. This is all fine.
The following code is an example of a mock test case doing exactly what I've described:
import unittest class NumberTest(unittest.TestCase): @classmethod def setUpClass(cls): cls.numbers = [] for x in range(1000): cls.numbers.append(x) @classmethod def tearDownClass(cls): del cls.numbers def test_number_is_even(self): for n in self.numbers: with self.subTest(current_number=n): self.assertEqual(n % 2, 0) def test_number_is_odd(self): for n in self.numbers: with self.subTest(current_number=n): self.assertEqual(n % 2, 1) def test_number_is_positive(self): for n in self.numbers: with self.subTest(current_number=n): self.assertTrue(n > 0) def test_number_is_negative(self): for n in self.numbers: with self.subTest(current_number=n): self.assertTrue(n < 0) if __name__ == '__main__': unittest.main() What bugs me here is that the lines for n in self.numbers: with self.subTest(current_number=n): . . . are repeated for each test method. Is there any way to avoid this? I know I could simply clump all self.assert statements together in a single method, but this defeats the purpose of having different tests for different aspects in the first place.
In my mind the "ideal" solution would be to, somehow, yield the values from the iterable (maybe through the setUp method? No clue) and pass these values to each test method before yielding the next one. but I have no idea how to actually do this, especially since it involves a context manager... Has anyone got any other solutions, or are there simply no workarounds for this?
setUpClassmethod. But now that I wrote this, I realize that this may not be unit-testing at all... since I'm testing different instances of the class, not the code itself. I'm not used to unit-tests so I may have approached the problem with the wrong mindset.