テスト要件
あらゆる動作変更には、その正当性を証明し、デバッグの容易性を維持するためのテストを含める必要があります。
基本的な期待値
ほとんどの機能開発において、以下の項目を網羅するテストを追加または更新してください。
- パイプラインのビルドにおける正確性（期待される断片／文字列の形式）。
- 動作の解析/検証（Capsネゴシエーションと検証の失敗）。
- ランタイム時の動作（該当する場合、
run、プッシュ/プル、およびクリーンアップの処理）。 - 診断の品質（
PipelineReport：障害発生時の状況における有用性）。
変更に応じて必要なテストの種類
新しいノードまたはノードグループ
- 決定的なフラグメント生成のためのユニットレベルのチェック。
- 上限値やリンクに関する前提条件の検証/解析範囲。
- ノードが実際のチェーンで正常に機能することを示す、少なくとも1つの統合パスが必要です。
ランタイム/パイプラインのオーケストレーションに関する変更点
- 期待される出力結果に対する正常な動作を検証するテスト。
- タイムアウト、プラグインの欠落、または無効なグラフ条件に対する、エラー発生時のテスト。
- 状態管理が変更された場合の、テスト終了時やライフサイクルにおける安全性の検証。
公開 API の署名変更
- 変更された公開ヘッダーや使用箇所をテストするコンパイル時のカバレッジを追加または更新します。
- 改行を許可しない拡張機能については、既存のコードが引き続きコンパイルできることを確認してください。
- 承認された破壊的な変更については、API の置き換えパスを検証するための移行に重点を置いたテスト/サンプルを含めてください。
Pythonバインディングの変更（python/、pyneat）
python/testsの下で、pytestのテストカバレッジを追加/更新します。- 相互運用に関する契約を網羅する（NumPy/PyTorch DLPack のパス、コピーとゼロコピーの動作）。
- インストールされたホイールまたは編集可能なインストールに対して、少なくとも1つのインポート/スモークテストを追加してください。
診断機 能または監視機能の変更
- レポートのフィールドの追加/変更に関するテスト。
- ストリーミングスレッドからデータが更新される際の、並行処理における安全な動作。
回帰と決定論のポリシー
- バグの修正には、リグレッションテストを含める必要があります。
- 決定的な命名と安定したパイプライン生成を検証するテストを優先してください。
- 出力が意図的に非決定的な場合、その理由を明記し、アサーションを安定した不変条件に限定してください。
スキップポリシー
- スキップパスは、通常の制御フローではなく、例外として扱う。
- 厳格なテスト（デフォルト設定）では、必要なランタイム、ツール、またはテスト用データが存在しないためにテストが実行できない場合、テストは失敗しなければなりません。
- 明示的に「
long」とラベル付けされたテストのみが、 スキップのセマンティクス（return 77）を使用でき、かつ、毎週実行されるテストに適用されます。 - 新しいテストの追加によって、厳密なパスに
skip_test(...)が導入されるべきではありません。
実用的なコマンド
プロジェクトのビルドのエントリーポイントを使用してください。
./build.sh --all
ドキュメントに影響を与える変更の場合、以下のコマンドも実行してください。
./build.sh --doc
サポートされているすべてのビルド/テストモードについては、構築する を参照してください。
貢献者向け チェックリスト
プルリクエストを開いたり、マージする前に：