The main drawback will be that won't be able to take advantage of setUpTestData to perform costly data creation _once_ for all the tests attached to the same TestCase.
Splitting the suite per test will likely force setUpTestData to be called once per process that has at least once one test of the TestCase assigned to it. A better strategy might be to avoid splitting TestCases among processes but order the suite of TestCase by the number of tests attached to them to _larger_ TestCases are run first just like you would normally pack items in decreasing size to optimize for reduced aggregate space. If you have metrics around the average cumulative duration of each TestCase (e.g. computed from previous CI runs) it should be an even better heuristic than len(TestCase.tests). Cheers, Simon Le vendredi 18 mars 2022 à 08:23:48 UTC-4, alan....@gmail.com a écrit : > Django only offers the possibility of parallelizing tests by splitting > TestCases among processes. As the number of tests per TestCase class can be > very different, it seems that splitting individual tests among processes > would make more sense. I have replaced partition_suite_by_case() in > test/runner.py with a new method that partitions the tests in the test > suite evenly among the processes and at first sight it works well. Is there > any known downfall in doing so? > > Thanks in advance! > > Regards, > Alan > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5709f600-25ce-4e0a-af34-0e453f67072bn%40googlegroups.com.
