{"id":7106,"library":"concurrencytest","title":"concurrencytest","description":"The `concurrencytest` library, currently at version 0.1.11, enables parallel execution of standard Python `unittest` test suites across multiple worker processes. It aims to speed up test execution by leveraging CPU cores. The library is actively maintained, with its latest release in March 2026, and provides mechanisms to control the number of worker processes and how tests are distributed among them.","status":"active","version":"0.1.11","language":"en","source_language":"en","source_url":"https://github.com/cgoldberg/concurrencytest","tags":["concurrency","parallel","test","unittest","testing"],"install":[{"cmd":"pip install concurrencytest","lang":"bash"}],"dependencies":[],"imports":[{"note":"The core class for wrapping a unittest.TestSuite to enable concurrent execution.","symbol":"ConcurrentTestSuite","correct":"from concurrencytest import ConcurrentTestSuite"},{"note":"The default make_tests implementation, used to configure fork-based worker processes. It is typically passed as an argument to ConcurrentTestSuite.","symbol":"fork_for_tests","correct":"from concurrencytest import fork_for_tests"},{"note":"The default test partitioning strategy (round-robin), which distributes individual test cases evenly across workers. Can cause setUpClass/tearDownClass to run multiple times.","symbol":"partition_tests","correct":"from concurrencytest import partition_tests"},{"note":"An alternative partitioning strategy that groups all tests from the same TestCase class onto a single worker, preserving setUpClass/tearDownClass semantics.","symbol":"partition_tests_by_class","correct":"from concurrencytest import partition_tests_by_class"}],"quickstart":{"code":"import time\nimport unittest\nfrom concurrencytest import ConcurrentTestSuite, fork_for_tests\n\nclass ExampleTestCase(unittest.TestCase):\n    def test_slow_1(self):\n        time.sleep(0.1)\n        self.assertTrue(True)\n\n    def test_slow_2(self):\n        time.sleep(0.1)\n        self.assertEqual(1 + 1, 2)\n\n    def test_fast_3(self):\n        self.assertFalse(False)\n\nif __name__ == '__main__':\n    # Load tests from current file\n    suite = unittest.defaultTestLoader.loadTestsFromTestCase(ExampleTestCase)\n    \n    # Run tests concurrently using 2 processes\n    # The default is fork_for_tests() which uses os.cpu_count() processes\n    concurrent_suite = ConcurrentTestSuite(suite, fork_for_tests(2))\n    \n    runner = unittest.TextTestRunner(verbosity=2)\n    runner.run(concurrent_suite)","lang":"python","description":"This quickstart demonstrates how to set up a `unittest.TestCase` and run its tests concurrently using `concurrencytest`. It shows how to load a test suite and wrap it with `ConcurrentTestSuite`, specifying the number of worker processes."},"warnings":[{"fix":"Use a Unix-like environment or consider alternative parallel testing frameworks if Windows compatibility is critical.","message":"The `fork_for_tests` implementation, and thus `concurrencytest` itself, relies on `os.fork()`. This means it is only compatible with Unix-like operating systems (Linux, macOS) and will not work on Windows.","severity":"gotcha","affected_versions":"All versions"},{"fix":"To preserve `setUpClass`/`tearDownClass` lifecycle semantics, explicitly use `partition_tests_by_class` when initializing `ConcurrentTestSuite`, e.g., `ConcurrentTestSuite(suite, fork_for_tests(num_workers, partition_tests_by_class))`.","message":"When using the default `partition_tests` strategy (round-robin), `unittest.TestCase` methods like `setUpClass` and `tearDownClass` may run multiple times if tests from the same class are distributed to different worker processes. This can lead to unexpected test state or resource management issues.","severity":"gotcha","affected_versions":"All versions"},{"fix":"Ensure each test creates its own resources and cleans them up. Avoid shared global state or use process-safe synchronization primitives (e.g., multiprocessing.Lock, Queue) if inter-process communication is absolutely necessary.","message":"Test cases must be designed to be independent and self-contained when run concurrently. Shared mutable state between tests or processes without proper synchronization can lead to race conditions, flakiness, or incorrect results that are hard to debug.","severity":"gotcha","affected_versions":"All versions"}],"env_vars":null,"last_verified":"2026-04-16T00:00:00.000Z","next_check":"2026-07-15T00:00:00.000Z","problems":[{"fix":"The library relies on `os.fork()`, which is not available on Windows. Run tests on Linux or macOS, or within a WSL (Windows Subsystem for Linux) environment.","cause":"Attempting to run `concurrencytest` on a Windows operating system.","error":"AttributeError: 'module' object has no attribute 'fork'"},{"fix":"Initialize `ConcurrentTestSuite` with the `partition_tests_by_class` strategy to ensure all tests from a given `TestCase` class run on the same worker process. Example: `ConcurrentTestSuite(suite, fork_for_tests(partition_func=partition_tests_by_class))`.","cause":"The default test partitioning strategy (`partition_tests`) distributes individual test methods across workers, potentially splitting tests from a single `TestCase` class. This causes `setUpClass` and `tearDownClass` to be executed by each worker that gets a test from that class.","error":"setUpClass or tearDownClass runs unexpectedly multiple times or causes incorrect test state."},{"fix":"Review test logic for any reliance on global variables, shared file system resources, or database state that is not reset or managed in a process-safe manner between tests. Make tests entirely independent of each other's execution order or state.","cause":"Likely due to race conditions or shared mutable state between test processes that is not properly synchronized. Each test is expected to run in its own isolated process.","error":"Tests fail intermittently or produce inconsistent results when run concurrently."}]}