@@ -20,22 +20,15 @@ to follow.
20
20
21
21
Choosing what module you want to increase test coverage for can be done in a
22
22
couple of ways.
23
- A third-party website at http://coverage.livinglogic.de/ provides an
24
- overall view of how good coverage is for various modules (you will want to
25
- focus on those in the ``Lib `` directory as those are the pure Python modules
26
- from Python's stdlib, and thus easier to work with than the C extension
27
- modules). But since this is a third-party site we cannot promise that it will
28
- always be accessible or have useful information (i.e., be working properly).
23
+ You can simply run the entire test suite yourself with coverage turned
24
+ on and see what modules need help. This has the drawback of running the entire
25
+ test suite under coverage measuring which takes some time to complete, but you
26
+ will have an accurate, up-to-date notion of what modules need the most work.
29
27
30
28
Another is to follow the examples below and simply see what
31
29
coverage your favorite module has. This is "stabbing in the dark", though, and
32
30
so it might take some time to find a module that needs coverage help.
33
31
34
- Finally, you can simply run the entire test suite yourself with coverage turned
35
- on and see what modules need help. This has the drawback of running the entire
36
- test suite under coverage measuring which takes some time to complete, but you
37
- will have an accurate, up-to-date notion of what modules need the most work.
38
-
39
32
Do make sure, though, that for any module you do decide to work on that you run
40
33
coverage for just that module. This will make sure you know how good the
41
34
explicit coverage of the module is from its own set of tests instead of from
0 commit comments