| OLD | NEW |
| (Empty) |
| 1 .. _subprocess: | |
| 2 | |
| 3 ====================== | |
| 4 Measuring subprocesses | |
| 5 ====================== | |
| 6 | |
| 7 :history: 20100224T201800, new for 3.3. | |
| 8 :history: 20100725T211700, updated for 3.4. | |
| 9 | |
| 10 | |
| 11 Complex test suites may spawn subprocesses to run tests, either to run them in | |
| 12 parallel, or because subprocess behavior is an important part of the system | |
| 13 under test. Measuring coverage in those subprocesses can be tricky because you | |
| 14 have to modify the code spawning the process to invoke coverage.py. | |
| 15 | |
| 16 There's an easier way to do it: coverage.py includes a function, | |
| 17 :func:`coverage.process_startup` designed to be invoked when Python starts. It | |
| 18 examines the ``COVERAGE_PROCESS_START`` environment variable, and if it is set, | |
| 19 begins coverage measurement. The environment variable's value will be used as | |
| 20 the name of the :ref:`configuration file <config>` to use. | |
| 21 | |
| 22 When using this technique, be sure to set the parallel option to true so that | |
| 23 multiple coverage.py runs will each write their data to a distinct file. | |
| 24 | |
| 25 | |
| 26 Configuring Python for subprocess coverage | |
| 27 ------------------------------------------ | |
| 28 | |
| 29 Measuring coverage in subprocesses is a little tricky. When you spawn a | |
| 30 subprocess, you are invoking Python to run your program. Usually, to get | |
| 31 coverage measurement, you have to use coverage.py to run your program. | |
| 32 Your subprocess won't be using coverage.py, so we have to convince Python | |
| 33 to use coverage even when not explicitly invokved. | |
| 34 | |
| 35 To do that, we'll configure Python to run a little coverage.py code when it | |
| 36 starts. That code will look for an environment variable that tells it to | |
| 37 start coverage measurement at the start of the process. | |
| 38 | |
| 39 To arrange all this, you have to do two things: set a value for the | |
| 40 ``COVERAGE_PROCESS_START`` environment variable, and then configure Python to | |
| 41 invoke :func:`coverage.process_startup` when Python processes start. | |
| 42 | |
| 43 How you set ``COVERAGE_PROCESS_START`` depends on the details of how you create | |
| 44 subprocesses. As long as the environment variable is visible in your subprocess
, | |
| 45 it will work. | |
| 46 | |
| 47 You can configure your Python installation to invoke the ``process_startup`` | |
| 48 function in two ways: | |
| 49 | |
| 50 #. Create or append to sitecustomize.py to add these lines:: | |
| 51 | |
| 52 import coverage | |
| 53 coverage.process_startup() | |
| 54 | |
| 55 #. Create a .pth file in your Python installation containing:: | |
| 56 | |
| 57 import coverage; coverage.process_startup() | |
| 58 | |
| 59 The sitecustomize.py technique is cleaner, but may involve modifying an existing | |
| 60 sitecustomize.py, since there can be only one. If there is no sitecustomize.py | |
| 61 already, you can create it in any directory on the Python path. | |
| 62 | |
| 63 The .pth technique seems like a hack, but works, and is documented behavior. | |
| 64 On the plus side, you can create the file with any name you like so you don't | |
| 65 have to coordinate with other .pth files. On the minus side, you have to create | |
| 66 the file in a system-defined directory, so you may need privileges to write it. | |
| OLD | NEW |