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 |