A slightly better fix for #627.

The first test should run fine, even if the number of processors is one.
That's because we explicitly tell multiprocess to use two process.
However, the second test asks multiprocess for the CPU count, and that's
where we run into a problem.  As a result, we'll only check the cpu
count in TestConcurrentSharedWithAutomaticProcessesCount.

1 files changed, 7 insertions, 4 deletions

diff --git a/functional_tests/test_multiprocessing/test_concurrent_shared.py b/functional_tests/test_multiprocessing/test_concurrent_shared.py
index d0318ff..a6fc203 100644
--- a/functional_tests/test_multiprocessing/test_concurrent_shared.py
+++ b/functional_tests/test_multiprocessing/test_concurrent_shared.py
@@ -22,10 +22,6 @@ class TestConcurrentShared(MPTestBase):
         # capturing.
         MPTestBase.setUp(self)
 
-        if multiprocessing.cpu_count() < 2:
-            raise unittest.SkipTest(
-                    "At least 2 cpus required for this test; skipping")
-
     def runTest(self):
         assert 'Ran 2 tests in 1.' in self.output, "make sure two tests use 1.x seconds (no more than 2 seconds)"
         assert str(self.output).strip().endswith('OK')
@@ -34,3 +30,10 @@ class TestConcurrentShared(MPTestBase):
 class TestConcurrentSharedWithAutomaticProcessesCount(TestConcurrentShared):
     """Make sure negative numbers are handled gracefully."""
     processes = -1
+
+    def setUp(self):
+        if multiprocessing.cpu_count() < 2:
+            raise unittest.SkipTest(
+                    "At least 2 cpus required for this test; skipping")
+
+        TestConcurrentShared.setUp(self)