ブラックボックス？ステートボックス？ - Start! Ruby

ブラックボックス？ステートボックス？

どちらかというと設計に該当する考え方。しかし、そのコードに与える影響の強さは、フローチャート以上。
ブラックボックスやステートボックスの考え方自体は、構造化手法とそれに伴うモジュール化の時代から存在している。

ブラックボックス・テスト？

ブラックボックスとは、あるクラスの公開アクセッサに注視して、そのインタフェースを明らかにすること。
じっさいのコードやオブジェクトの状態は考慮に入れないで行う。

クラス

• そのクラスの公開されている部分（メソッドやプロパティ等）が、外部からアクセス可能になっていること。

メソッド/プロパティ

• そのメソッドのIN値が明らかになっていること。
  • IN値に閾値があるときは、それの範囲
  • IN値に特値（特別な値）があるときは、その値
  • IN値がオブジェクトの場合：そのステートに制限があるときは、ステート
• IN値が対象外のときの動作が明らかになっていること。
  • 例外の発行
  • 単なる無動作
• IN値を与えたときのOUT値が明らかになっていること。
  • IN値に閾値があるときは、とくにその境界値のOUT値
  • IN値に特値があるときは、その場合のOUT値
  • クラスにステートがあり、それによりOUT値が左右される場合は、ステート別のOUT値

ステートボックス・テスト？

ステートボックスとは、あるクラスのオブジェクトのステートやそのクラスが他に及ぼす影響に注視して、そのステート・影響を明らかにすること。
じっさいのコードは考慮に入れないで行う。

クラス

• そのクラス(オブジェクト)のステートと遷移が明らかになっていること。

メソッド

• そのメソッドによる、クラス(オブジェクト)のステートの変更が明らかになっていること。
  • IN値によるステートの変化値
  • IN値と現ステートの組み合わせによるステートの変化値
• そのメソッドによる、外部への影響が明らかになっていること。
  • DBやファイル等、記録媒体への影響
  • システム的なオブジェクトなど、自身に管理権限のない他のオブジェクトへの影響
• そのメソッドでおこる、外部からの影響が明らかになっていること。
  • DBやファイル等、記録媒体からの影響
  • システム的なオブジェクトなど、自身に管理権限のない他のオブジェクトからの影響

これらのインタフェースを意識していくと

しぜんに、次のような設計を心がけるようになっていく。

1. メソッドの引数には、なるべく閾値を設けない。設ける場合も、列挙(enum)を使うなどして閾値外にならないように工夫する。
2. クラスのステートは、必要最低限に構成するようになる。複数のステートが絡み複雑になる場合は、クラス分けを考え出す。
3. 外部への影響は、なるべく排除するように考え出す。外部からの影響(変更可能性)も必要最低限へ。

TDDではどう扱うか？

1. どうテストを書いたらいいかわからなくなった！そんな時の指針になる。
2. ただし、あまりガチガチに縛られないように。

---