You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: tests/code-cov.md
+45-15Lines changed: 45 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,31 +10,44 @@ using code coverage effectively.
10
10
A good practice is to ensure that every line of your code runs at least once
11
11
during your test suite. This helps you:
12
12
13
-
- Identify untested parts of your codebase.
14
-
- Catch bugs that might otherwise go unnoticed.
15
-
- Build confidence in your software's stability.
13
+
-**Identify untested parts:** Parts of your codebase that are not
14
+
covered by tests.
15
+
-**Catch bugs:** Bugs that might otherwise go unnoticed.
16
+
-**Build confidence:** Confidence in your software's stability.
16
17
17
18
## Limitations of code coverage
18
19
19
20
While high code coverage is valuable, it has its limits:
20
21
21
-
-**Difficult-to-test code:** Some parts of your code might be challenging to
22
-
test, either due to complexity or limited resources.
23
-
-**Missed edge cases:** Running all lines of code doesn’t guarantee that edge
24
-
cases are handled correctly.
22
+
-**Difficult-to-test code:** Some parts of your code might be
23
+
challenging to test, either due to complexity or limited resources.
24
+
-**Missed edge cases:** Running all lines of code doesn't guarantee
25
+
that edge cases are handled correctly.
25
26
26
27
Ultimately, you should focus on how your package will be used and ensure your
27
28
tests cover those scenarios adequately.
28
29
29
30
## Tools for analyzing Python package code coverage
30
31
31
-
Some common services for analyzing code coverage are [codecov.io](https://about.codecov.io/) and [coveralls.io](https://coveralls.io/). These projects are free for open source tools and will provide dashboards that tell you how much of your codebase is covered during your tests. We recommend setting up an account (on either CodeCov or Coveralls) and using it to keep track of your code coverage.
32
+
Some common services for analyzing code coverage are
33
+
[codecov.io](https://about.codecov.io/) and [coveralls.io](https://coveralls.io/).
34
+
These projects are free for open source tools and provide dashboards that
35
+
show how much of your codebase is covered during your tests. We recommend
36
+
setting up an account (on either CodeCov or Coveralls) and using it to
37
+
keep track of your code coverage.
32
38
33
39
:::{figure} ../images/code-cov-stravalib.png
34
40
:height: 450px
35
41
:alt: Screenshot of the code cov service - showing test coverage for the stravalib package. This image shows a list of package modules and the associated number of lines and % lines covered by tests. At the top of the image, you can see what branch is being evaluated and the path to the repository.
36
42
37
-
The CodeCov platform is a useful tool if you wish to track code coverage visually. Using it, you can not only get the same summary information that you can get with the **pytest-cov** extension. You can also see what lines are covered by your tests and which are not. Code coverage is useful for evaluating unit tests and/or how much of your package code is "covered". It, however, will not evaluate things like integration tests and end-to-end workflows.
43
+
The CodeCov platform is a useful tool if you wish to track code coverage
44
+
visually. Using it, you can get the same summary information that you can get
45
+
with the **pytest-cov** extension. You can also see what lines are covered by
46
+
your tests and which are not. Code coverage is useful for evaluating
47
+
[unit tests](test-types.md#unit-tests) and/or how much of your package code
48
+
is "covered". It, however, will not evaluate things like
49
+
[integration tests](test-types.md#integration-tests) and
50
+
[end-to-end workflows](test-types.md).
38
51
39
52
:::
40
53
@@ -46,21 +59,38 @@ You can also create and upload typing reports to CodeCov.
46
59
47
60
## Exporting Local Coverage Reports
48
61
49
-
In addition to using services like CodeCov or Coveralls, you can generate local coverage reports directly using the **coverage.py** tool. This can be especially useful if you want to create reports in Markdown or HTML format for offline use or documentation.
62
+
In addition to using services like CodeCov or Coveralls, you can generate
63
+
local coverage reports directly using the **coverage.py** tool. This can be
64
+
especially useful if you want to create reports in Markdown or HTML format for
65
+
offline use or documentation.
50
66
51
67
To generate a coverage report in **Markdown** format, run:
52
68
53
69
```bash
54
-
$ python -m coverage report --format=markdown
70
+
python -m coverage report --format=markdown
55
71
```
56
-
This command will produce a Markdown-formatted coverage summary that you can easily include in project documentation or share with your team.
57
72
58
-
To generate an HTML report that provides a detailed, interactive view of which lines are covered, use:
73
+
This command will produce a Markdown-formatted coverage summary that you can
74
+
include in project documentation or share with your team.
75
+
76
+
To generate an HTML report that provides a detailed, interactive view of which
77
+
lines are covered, use:
59
78
60
79
```bash
61
80
python -m coverage html
62
81
```
63
82
64
-
The generated HTML report will be saved in a directory named htmlcov by default. Open the index.html file in your browser to explore your coverage results.
83
+
The generated HTML report will be saved in a directory named `htmlcov` by
84
+
default. Open the `index.html` file in your browser to explore your coverage
85
+
results.
86
+
87
+
These local reports are an excellent way to quickly review coverage without
88
+
setting up an external service.
89
+
90
+
## Next steps
65
91
66
-
These local reports are an excellent way to quickly review coverage without setting up an external service.
92
+
Writing meaningful tests is the foundation of useful coverage.
93
+
See [Write tests](write-tests.md) and [Test types](test-types.md)
94
+
to design strong test suites. Run coverage regularly both
95
+
[locally](run-tests.md) and in [continuous integration](tests-ci.md)
Copy file name to clipboardExpand all lines: tests/index.md
+19-18Lines changed: 19 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,6 @@ In this section, you will learn more about the importance of writing
9
9
tests for your Python package and how you can set up infrastructure
10
10
to run your tests both locally and on GitHub.
11
11
12
-
13
12
:::::{grid} 1 1 3 2
14
13
:class-container: text-center
15
14
:gutter: 3
@@ -20,9 +19,8 @@ to run your tests both locally and on GitHub.
20
19
:link-type: doc
21
20
:class-card: left-aligned
22
21
23
-
Learn more about the art of writing tests for your Python package.
24
-
Learn about why you should write tests and how they can help you and
25
-
potential contributors to your project.
22
+
Learn about the importance of writing tests for your Python
23
+
package and how they help you and potential contributors.
26
24
:::
27
25
::::
28
26
@@ -32,8 +30,8 @@ potential contributors to your project.
32
30
:link-type: doc
33
31
:class-card: left-aligned
34
32
35
-
There are three general types of tests that you can write for your Python
36
-
package: unit tests, integration tests and end-to-end (or functional) tests. Learn about all three.
33
+
Understand the three test types: unit, integration, and
34
+
end-to-end tests. Learn when and how to use each.
37
35
:::
38
36
::::
39
37
@@ -43,8 +41,8 @@ package: unit tests, integration tests and end-to-end (or functional) tests. Lea
43
41
:link-type: doc
44
42
:class-card: left-aligned
45
43
46
-
If you expect your users to use your package across different versions
47
-
of Python, then using an automation tool such as nox to run your tests is useful. Learn about the various tools that you can use to run your tests across python versions here.
44
+
Learn about testing tools like pytest, nox, and tox to run
45
+
tests across different Python versions on your computer.
48
46
:::
49
47
::::
50
48
@@ -54,21 +52,23 @@ of Python, then using an automation tool such as nox to run your tests is useful
54
52
:link-type: doc
55
53
:class-card: left-aligned
56
54
57
-
Continuous integration platforms such as GitHub Actions can be
58
-
useful for running your tests across both different Python versions
59
-
and different operating systems. Learn about setting up tests to run in Continuous Integration here.
55
+
Set up continuous integration with GitHub Actions to run
56
+
tests across Python versions and operating systems.
0 commit comments