Djangoで設定ファイルを利用してカバレッジレポートを作成する方法
概要
Django のコードを書いた際にテストを買いたり、書かなかったりすることがあります。
基本的にテストコードは書いた方が良いのですが、書いたとしても正しくすべての条件を通っているのかを確認するのは大変時間がかかります。
そういった際に、自動で条件を通っているかどうかを確認できる方法について調べた内容を載せます。
検証環境について
- python 3.9.4
ライブラリについて
coverage==5.5
Django でカバレッジ測定するためのおすすめの方法について
.coveragerc
というファイルを作成して、カバレッジ測定に使用する coverage
コマンドの設定を作成することをおすすめします。
理由は、コマンドの実行時に指定するオプションを省略できるからです。
もちろん省略しなくても動きますし、ci 環境で動かす際にも必須ではありません。
ただし、オプションが多くなることで、実行されているコマンドが読みづらくなってしまい、メンテナンスに時間がかかるかもしれません。
設定ファイルは可能な限り外に出すことをおすすめします。
.coveragerc の記述方法について
先に例を載せます。
[run]
omit =
./*/migrations/*
include =
./apps/*
omit
や include
と書かれている箇所を他の値に書き換えたい場合は、ドキュメントを参考にすると良いです。
例えば、 omit
は指定したファイルを除外し、 include
はカバレッジの対象を指定できます。
The --include and --omit flags specify lists of file name patterns. They control which files to report on, and are described in more detail in Specifying source files.
rcfile
というオプションもあるので、環境別で rc ファイルを用意しても良いかもしれません。
ステージ環境様の設定ファイル(.stage.coveragerc
)を用意した場合、実行時のコマンドは以下のようになります。
coverage run --rcfile=.stage.coveragerc manage.py test
あとは以下のコマンドを実行するだけでカバレッジを測定できます。
coverage run manage.py test
すると、カレントディレクトリに .coverage
という隠しファイルが作成されます。
次に、以下のコマンドを実行してレポートを作成します。
coverage html
コマンドを実行すると、htmlcov
ディレクトリが作成され、その中に静的ファイルが作成されます。
その中からindex.html
をブラウザで開くとカバレッジを確認できます。
実行したコマンドについては、run 同様に.coveragerc
に記載できます。
[html]
directory = coverage_html_report
このように設定すると、テスト結果がcoverage_html_report
以下に作成され、どののテストから実行されたのかが分かるようになります。
設定ファイルの例と実行コマンドの例
解説だけだとイマイチ分かりづらいと思いますので、設定ファイルと、実行時のコマンドを載せます。
設定ファイルの例
[run]
omit =
./*/migrations/*
venv/*
include =
*/core/*
dynamic_context = test_function
[html]
directory = coverage_html_report
show_contexts = True
実行コマンドの例
レポートを作成し、その結果をブラウザで開くコマンドです。
rm -r coverage_html_report 2>/dev/null
coverage run manage.py test
coverage html
open coverage_html_report/index.html
おまけ
include と source のどちらを使ったほうが良いか
ドキュメントや「python coverage」等で検索すると、以下のように source を使ったサンプルが見つかることがあります。
coverage run --source='.' manage.py test myapp
これでも間違いでは無いと思いますが、プロジェクトが大きくなるにつれて、測定対象のファイルを細かく調整したくなってくるはずです。
そのときに--source
での指定だと、直接対象を指定することになるため規模が大きくなった際の指定に手間がかかります。
こういった設定ファイルはアプリケーションへの直接的な影響は起こりづらいですが、テストの設定を更新するために開発が止まってしまうことがあります。
可能な限り拡張しやすい設定を選んだ方が良いという理由から、--include
の使用をおすすめします。
.coveragerc
にsource
とinclude
の指定をそれぞれ書いた場合は、以下の違いがあります。
- source はパッケージかディレクトリを指定する
- include はファイルのパターンを設定する
source と include をそれぞれ同じパッケージを指定した場合の違いについて
core
パッケージがどこかに存在するプロジェクトで、.coveragerc
に以下のように記載すると実行時にメッセージが出力されます。
[run]
source =
*/core/*
結果
Coverage.py warning: Module */core/* was never imported. (module-not-imported)
Coverage.py warning: No data was collected. (no-data-collected)
レポート対象のデータが見つからなかったということです。
正しく実行されるようにするには、source
の指定方法を./core/*
とする必要があります。
なので、「パッケージのどこかにある core パッケージ以下を対象にする」といったことはできません。
同様の手順でinclude
についても設定をして検証します。
[run]
include =
*/core/*
結果
Ran 2 tests in 0.001s
FAILED (failures=1)
source とは異なり、途中に存在する core パッケージも対象となります。
Discussion