Blender Sverchok testing ドキュメントを見る

はじめに

ノードのカスタマイズがしたくなったので関連するっぽいドキュメントを読んでみます

参照元

github.com

Testing

まえがき

このドキュメントはSverchokのコードをテストする私達のアプローチを書いています。(主に開発者向け)

主要な考え
– コードは良い方が良いです
– テストするまではコードの良し悪しはわかりません
– 変更後にテストを自動で行うのは良いアイデアです。これはあなたのコードが良くなったのか悪くなったのかを教えてくれます。
– TDDと同様の考え方に基づいています
– ドグマ(TDDが教義)としてSverchokに適用しません。その理由
– 自動テストは代償があります。主に人的なリソースです。それは私達が多く持っているものでは有りません
– Sverchokのコードの一部は、ユーザーとの対話(GUI)に関するものです。そのようなコードは理論的には自動的にテストすることができますが、Sverchokのためにそれを価格に見合う価値があるとは考えていません。
– なので複雑すぎず、重すぎず、壊れすぎない自動テストを書きます。GUI関連や、複雑なもの、プログラムから設定する項目が多いコードは手動でテストします

実装

Sverchokの自動テストは標準PythonのUnittestモジュールに基づいています。 sverchok.utils.testingモジュールにはいくつかのutilityメソッドが有り、テストケースのいくつかのベースクラスがあります。より詳細な情報についてはモジュール内のdocstringを参照してください。Testケース自体は tests/にあります。テストファイルの名前は*_test.pyである必要があります。テストケースは自分用のテストをつくる例として自由に使ってください。テストデータファイルはtests/references/ディレクトリに保存されています。.blend.gz.jsonファイルが比較のためのパターン/参照として使われます。

テストケースは2つの方法で実行できます
Blenderから実行。これを行うためにはSverchokの設定にあるDevelopper Modeを有効にしてください。そうすればN-Panel上にTestingパネルが登場し、そこにRun all testsボタンが表示されます。Sverchokのログからテスト結果を確認する事ができます。
コマンドラインから実行。run_test.shがルートディレクトリにあります。(これはbash用です。windowsのbatやpowershellに詳しければ同様のスクリプトが簡単にかけると私は想像しています)。もしblender実行ファイルのパスが通っていない場合は、パスを通してください。このような感じでBLENDER=~/soft/blender-2.79-linux-glibc219-x86_64/blender ./run_tests.sh.

pullリクエストを出す前に少なくともテストを行ってください

継続的インテグレーション

GitHubプロジェクトにはTravisのCI統合が設定されています。現在の状況はこちらから確認できます。Travis CI ビルドは、以下のイベントで自動的にトリガーされるように設定されています。

  • masterブランチへのプッシュ
  • masterブランチへのプッシュリクエスト、またはプルリクエストのブランチへのプッシュ。

Pullリクエストによるビルドトリガーの状態はGithubインタフェースに直接表示されます。もしあなたのpullリクエストがテストでブレークした場合、そのような状態にはなりません。その場合はコードを修正するか、テストに問題がある場合は、テスト自身のコードを更新してください。

さらに、プルリクエストごとにいくつかの自動テストを追加するのは良いアイデアです。例えば、新しい機能を追加した場合、そのためのテストを追加してください(そのようなテストを書くのがそれほど難しくない場合には、それ以外の場合は手動でテストを行うだけです)。

タイトルとURLをコピーしました