Testen¶
Builds und Links¶
Build-Fehler¶
Ihr habt die Möglichkeit, vor der Veröffentlichung eurer Änderungen zu
überprüfen, ob eure Inhalte ordnungsgemäß erstellt werden. Hierfür hat
Sphinx einen pingelig (engl. nitpicky)-Modus, der mit der Option -n
aufgerufen werden kann,
also z.B. mit:
$ python -m sphinx -nb html docs/ docs/_build/
C:> python -m sphinx -nb html docs\ docs\_build\
Links¶
Ihr könnt auch automatisiert sicherstellen, dass die von euch angegebenen
Linkziele erreichbar sind. Unser Dokumentationswerkzeug Sphinx verwendet hierfür
einen linkcheck
-Builder, den ihr ggf. aufrufen
könnt mit:
$ python -m sphinx -b linkcheck docs/ docs/_build/
C:> python -m sphinx -b linkcheck docs\ docs\_build\
Die Ausgabe kann dann z.B. so aussehen:
$ python -m sphinx -b linkcheck docs/ docs/_build/
Running Sphinx v3.5.2
loading translations [de]... done
…
building [mo]: targets for 0 po files that are out of date
building [linkcheck]: targets for 27 source files that are out of date
…
(content/accessibility: line 89) ok https://bbc.github.io/subtitle-guidelines/
(content/writing-style: line 164) ok http://disabilityinkidlit.com/2016/07/08/introduction-to-disability-terminology/
…
( index: line 5) redirect https://cusy-design-system.readthedocs.io/ - with Found to https://cusy-design-system.readthedocs.io/de/latest/
…
(accessibility/color: line 114) broken https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbnhckmgdhmgdckeigabjfbddl - 404 Client Error: Not Found for url: https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbnhckmgdhmgdckeigabjfbddl
C:> python -m sphinx -b linkcheck docs\ docs\_build\
Running Sphinx v3.5.2
loading translations [de]... done
…
building [mo]: targets for 0 po files that are out of date
building [linkcheck]: targets for 27 source files that are out of date
…
(content/accessibility: line 89) ok https://bbc.github.io/subtitle-guidelines/
(content/writing-style: line 164) ok http://disabilityinkidlit.com/2016/07/08/introduction-to-disability-terminology/
…
( index: line 5) redirect https://cusy-design-system.readthedocs.io/ - with Found to https://cusy-design-system.readthedocs.io/de/latest/
…
(accessibility/color: line 114) broken https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbnhckmgdhmgdckeigabjfbddl - 404 Client Error: Not Found for url: https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbnhckmgdhmgdckeigabjfbddl
Kontinuierliche Integration¶
Ggf. könnt ihr auch automatisiert in eurer CI-Pipeline überprüfen, ob die Dokumentation gebaut wird und die Links gültig sind. In tox kann die Konfiguration folgendermaßen ergänzt werden:
[testenv:docs]
# Keep base_python in sync with ci.yml and .readthedocs.yaml.
base_python = py312
extras = docs
commands =
sphinx-build -n -T -W -b html -d {envtmpdir}/doctrees docs docs/_build/html
[testenv:docs-linkcheck]
base_python = {[testenv:docs]base_python}
extras = {[testenv:docs]extras}
commands = sphinx-build -W -b linkcheck -d {envtmpdir}/doctrees docs docs/_build/html
Anschließend könnt ihr z.B. für GitHub folgende Jobs definieren:
docs:
name: Build docs and run doctests
needs: build-package
runs-on: ubuntu-latest
steps:
- name: Download pre-built packages
uses: actions/download-artifact@v4
with:
name: Packages
path: dist
- run: tar xf dist/*.tar.gz --strip-components=1
- uses: actions/setup-python@v5
with:
# Keep in sync with tox.ini/docs and .readthedocs.yaml
python-version: "3.12"
cache: pip
- run: python -m pip install tox
- run: python -m tox run -e docs
reST-Formatierung¶
Ob die Sphinx-Dokumentation in gültigem reStructuredText-Format geschrieben ist, lässt sich mit sphinx-lint überprüfen. Dies binden wir üblicherweise in unsere pre-commit-Konfiguration ein:
- repo: https://github.com/sphinx-contrib/sphinx-lint
rev: v1.0.0
hooks:
- id: sphinx-lint
types: [rst]
Code¶
Mit der eingebauten Python-Bibliothek Doctest könnt ihr auch Code in
eurer Dokumentation mit der doctest.testfile()
-Methode testen:
import doctest
doctest.testfile("example.rst")
Dieses kurze Skript führt alle interaktiven Python-Beispiele aus, die in der
Datei example.rst
enthalten sind, und überprüft sie. Der Inhalt der
Datei wird so behandelt, als wäre er ein einziger riesiger Docstring.
Siehe auch
Ein einfaches Beispiel findet ihr in der Python-Dokumentation: Simple Usage: Checking Examples in a Text File.
Eine andere Möglichkeit, Code in Dokumentationen zu testen ist pytest-doctestplus.
Code-Formatierung¶
Die Formatierung von Code-Blöcken lässt sich mit blacken-docs überprüfen, das Black verwendet. Üblicherweise binden wir die Bibliothek über das pre-commit-Framework ein:
- repo: https://github.com/adamchainz/blacken-docs
rev: "v1.12.1"
hooks:
- id: blacken-docs
additional_dependencies:
- black
blacken-docs unterstützt aktuell die folgenden Black-Optionen:
Rechtschreibung¶
Die englische Rechtschreibung lässt sich überprüfen mit codespell. Es nutzt eine erweiterte
Version der auf Wikipedia
verfügbaren Wörterbücher. Ggf. könnt ihr jedoch auch
eigene Wörterbücher mit der --builtin
-Option bereitstellen.
Ihr könnt codespell
in der pyproject.toml
konfigurieren, z.B.:
[project.optional-dependencies]
docs = [
"...",
"codespell",
]
[tool.codespell]
ignore-words-list = "uint"
skip = "./.*, *.po, ./docs/_build"
count = true
quiet-level = 3
Ihr könnt codespell
automatisch vor jedem Git-Commit ausführen, indem ihr
folgendes in die .pre-commit-config.yaml
-Datei eintragt:
- repo: https://github.com/codespell-project/codespell
rev: v2.3.0
hooks:
- id: codespell
Vale geht über Rechtschreib- und Grammatikprüfungen hinaus. Es überprüft auch den Sprachstil: Wiederholt sich das Gesagte? Ist die Sprache zu informell? Ist die Ansprache inkonsistent? Werden unerwünschte Klischees bedient? Oder ist die Sprache sexistisch?
Vale wird von vielen Open-Source-Projekten genutzt, u.a. von
Mit Vale selbst kommen die folgenden Stile mit:
- Microsoft
Eine Implementierung des Microsoft Writing Style Guide.
Eine Implementierung des Styleguides für den Google developer documentation style guide.
- write-good
Eine Umsetzung der vom write-good-Linter erzwungenen Richtlinien.
- proselint
Eine Umsetzung der vom proselint-Linter erzwungenen Richtlinien.
- Joblint
Eine Umsetzung der vom Joblint-Linter erzwungenen Richtlinien.
Vale wird in der .vale.ini
-Datei konfiguriert:
StylesPath = styles
MinAlertLevel = suggestion
Packages = https://github.com/cusyio/cusy-vale/archive/refs/tags/v0.1.0.zip
[*.{md,rst}]
BasedOnStyles = cusy-de
Siehe auch
Anschließend solltet ihr ggf. eure .gitignore-Datei aktualisieren:
styles/*
Ihr könnt Vale für das pre-commit-Framework konfigurieren mit:
- repo: https://github.com/errata-ai/vale
rev: v3.7.1
hooks:
- id: vale sync
pass_filenames: false
args: [sync]
- id: vale
args: [--output=line, --minAlertLevel=error, .]
Docstrings-Coverage¶
interrogate prüft eure Codebasis auf fehlende Dokumentationsstrings und generiert ein shields.io-ähnliches Badge.
Ihr könnt interrogate
z.B. in der
pyproject.toml-Datei konfigurieren:
[project.optional-dependencies]
docs = [
"...",
"interrogate",
]
[tool.interrogate]
ignore-init-method = true
ignore-init-module = false
ignore-magic = false
ignore-semiprivate = false
ignore-private = false
ignore-module = false
ignore-property-decorators = false
fail-under = 95
exclude = ["tests/functional/sample", "setup.py", "docs"]
verbose = 0
omit-covered-files = false
quiet = false
whitelist-regex = []
ignore-regex = []
color = true
Siehe auch
Nun könnt ihr interrogate
in eure tox-Datei einfügen,
z.B. mit
[testenv:doc]
deps = interrogate
skip_install = true
commands =
interrogate --quiet --fail-under 95 src tests
Ihr könnt interrogate
auch mit pre-commit nutzen:
repos:
- repo: https://github.com/econchick/interrogate
rev: 1.7.0
hooks:
- id: interrogate
args: [--quiet, --fail-under=95]
pass_filenames: false