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 |