テストによる期待

このページでは、Dynamo に追加される新しいコードをテストする際に何を求めているのかについて説明します。

ここで、追加する新しいノードがあるとします。そこで、いくつかのテストを追加してみます。これには、次の 2 つの利点があります。

1. コードが機能しない場所を見つけるのに役立ちます。

2. 他のユーザによる変更でノードが壊れる場合、テストも壊れるはずです。この場合、テストで壊したユーザが修正作業に入る必要があります。テストで壊れない場合、ユーザのモデルが壊れた際に主に自分で対処することになります。

Dynamo でのテストは、ユニット テストとシステム テストの 2 種類に分けられます。

ユニット テスト

ユニット テストは、できる限り最小限のテストにとどめます。C# の Zero Touch ノードを使用して平方根を計算するノードを構築した場合、テストではその dll のみをテストし、そのコードに対して直接 C# の呼び出しを実行する必要があります。ユニット テストには Dynamo を含めるべきではありません。

テストには以下の内容を含める必要があります。

• 正常系テスト(通常の動作テスト)

• 異常系テスト(異常な入力に対しクラッシュしないか)

• リグレッション テスト(コードにバグが見つかった場合、再発しないようにテストを記述する)

テストはコンパクトかつ高速で、高い信頼性が必要です。テストの大部分はユニット テストになります。

システム テスト

システム テストでは複数のコンポーネントを操作し、連携する動作をテストします。このテストの使用および作成は慎重に行う必要があります。

その理由は、実行にコストがかかるためです。一連のテストをできる限り遅延なく実行し続ける必要があります。

システム テストを記述する際にまず必要なのは、こちらの図を見て、どのサブシステムが対象に入っているかを理解することです。

テストが失敗し始めたときにどこに問題があるかがすぐにわかるよう、相互に連動するブロックが増えるのに対応して進行する一連のテストを行うのが理想的です。

システム テストが必要になる例:

• 単一の要素ではなく複数の要素をトレースで保存する新しいタイプの Revit ノード

• データを異なる方法で表示する新しい Watch ノード

システム テストが不要である例:

• 新しい Math ノード

• 文字列処理ライブラリ

システム テストでは次のことを行う必要があります。

• 正しい動作をアサートする

• 異常な挙動がないことをアサートする(例外なしなど)