Use the pytest -q option for tidier ouput with multi-core CPUs (#9845)

JukkaL · web-flow · commit 7c0c1e7a1e86 · 2020-12-29T11:30:53.000Z
Without this option, pytest can print out many lines of garbage
if there are more than 8 parallel processes being used. This can
result in test output being hard to read, and it also looks bad.

Since many new CPUs have 6+ cores, and 16+ cores are not unusual, it's
reasonable to use -q by default.
diff --git a/mypyc/README.md b/mypyc/README.md
@@ -73,7 +73,7 @@ Then install the dependencies:
 
 Now you can run the tests:
 
-    $ pytest mypyc
+    $ pytest -q mypyc
 
 Look at the [issue tracker](https://github.com/mypyc/mypyc/issues)
 for things to work on. Please express your interest in working on an
diff --git a/mypyc/doc/dev-intro.md b/mypyc/doc/dev-intro.md
@@ -199,7 +199,7 @@ Most mypyc test cases are defined in the same format (`.test`) as used
 for test cases for mypy. Look at mypy developer documentation for a
 general overview of how things work. Test cases live under
 `mypyc/test-data/`, and you can run all mypyc tests via `pytest
-mypyc`. If you don't make changes to code under `mypy/`, it's not
+-q mypyc`. If you don't make changes to code under `mypy/`, it's not
 important to regularly run mypy tests during development.
 
 When you create a PR, we have Continuous Integration jobs set up that
diff --git a/runtests.py b/runtests.py
@@ -59,14 +59,14 @@
     # Lint
     'lint': 'flake8 -j0',
     # Fast test cases only (this is the bulk of the test suite)
-    'pytest-fast': 'pytest -k "not (%s)"' % ' or '.join(ALL_NON_FAST),
+    'pytest-fast': 'pytest -q -k "not (%s)"' % ' or '.join(ALL_NON_FAST),
     # Test cases that invoke mypy (with small inputs)
-    'pytest-cmdline': 'pytest -k "%s"' % ' or '.join([CMDLINE,
-                                                      EVALUATION,
-                                                      STUBGEN_CMD,
-                                                      STUBGEN_PY]),
+    'pytest-cmdline': 'pytest -q -k "%s"' % ' or '.join([CMDLINE,
+                                                         EVALUATION,
+                                                         STUBGEN_CMD,
+                                                         STUBGEN_PY]),
     # Test cases that may take seconds to run each
-    'pytest-slow': 'pytest -k "%s"' % ' or '.join(
+    'pytest-slow': 'pytest -q -k "%s"' % ' or '.join(
         [SAMPLES,
          TYPESHED,
          PEP561,
@@ -75,10 +75,10 @@
          MYPYC_COMMAND_LINE,
          ERROR_STREAM]),
     # Test cases to run in typeshed CI
-    'typeshed-ci': 'pytest -k "%s"' % ' or '.join([CMDLINE, EVALUATION, SAMPLES, TYPESHED]),
+    'typeshed-ci': 'pytest -q -k "%s"' % ' or '.join([CMDLINE, EVALUATION, SAMPLES, TYPESHED]),
     # Mypyc tests that aren't run by default, since they are slow and rarely
     # fail for commits that don't touch mypyc
-    'mypyc-extra': 'pytest -k "%s"' % ' or '.join(MYPYC_OPT_IN),
+    'mypyc-extra': 'pytest -q -k "%s"' % ' or '.join(MYPYC_OPT_IN),
 }
 
 # Stop run immediately if these commands fail
diff --git a/test-data/unit/README.md b/test-data/unit/README.md
@@ -92,34 +92,36 @@ module:
 The unit test suites are driven by the `pytest` framework. To run all mypy tests,
 run `pytest` in the mypy repository:
 
-    $ pytest mypy
+    $ pytest -q mypy
 
 This will run all tests, including integration and regression tests,
-and will verify that all stubs are valid. This may take several minutes to run,
-so you don't want to use this all the time while doing development.
+and will verify that all stubs are valid. This may take several
+minutes to run, so you don't want to use this all the time while doing
+development. (The `-q` option activates less verbose output that looks
+better when running tests using many CPU cores.)
 
 Test suites for individual components are in the files `mypy/test/test*.py`.
 
 Note that some tests will be disabled for older python versions.
 
 If you work on mypyc, you will want to also run mypyc tests:
 
-    $ pytest mypyc
+    $ pytest -q mypyc
 
 You can run tests from a specific module directly, a specific suite within a
 module, or a test in a suite (even if it's data-driven):
 
-    $ pytest mypy/test/testdiff.py
+    $ pytest -q mypy/test/testdiff.py
 
-    $ pytest mypy/test/testsemanal.py::SemAnalTypeInfoSuite
+    $ pytest -q mypy/test/testsemanal.py::SemAnalTypeInfoSuite
 
     $ pytest -n0 mypy/test/testargs.py::ArgSuite::test_coherence
 
     $ pytest -n0 mypy/test/testcheck.py::TypeCheckSuite::testCallingVariableWithFunctionType
 
 To control which tests are run and how, you can use the `-k` switch:
 
-    $ pytest -k "MethodCall"
+    $ pytest -q -k "MethodCall"
 
 You can also run the type checker for manual testing without
 installing it by setting up the Python module search path suitably:
