あなたが落としたものは、テストコードですか、テストケースですか。

タイトルはアレだが、主旨は『テストを書け』であると理解した。同意。

 

qiita.com

 

テストを書いてと言われたら、

  1. テストコードを書く
  2. テスト項目(仕様)を書く

のとどっちが多いのだろうか。60万人とも80万人とも言われるエンジニアでアンケートを取ったら多分、後者の方が断然多いのではないだろうか。

ご存知のとおり、テストコードを書くというと仕様からコードが動くケースをコードで表現することになる。それに合わせて実際のプロダクションコードを書けば、仕様のとおり書けるわけだ。

後者もご存知のとおり、V字モデルとかW字モデルなどではテストフェーズに対応する設計の仕様をテストケースとして書き起こす。

ところが後者の場合、1つ問題がある。設計の仕様からテストケースを起こさず、コードからテストケースを起こしてしまうパターンである。このやり方をするとUTなどではバグが出ない。当たり前だが、コードに合わせているからである。

ではインフラエンジニアのテストはどうすればいいか。気を失いそうなほどのパラメータがあり、変更したパラメータの組み合わせでテストケースが必要なときもある。テスト対象の環境ごとにテストが必要となったり、仕様する端末の仕様も変わったりする。

インフラエンジニアがテストを書く前の上流設計の時点でテストの環境(端末、NW、サーバ構成)を整理し、テストの大項目、中項目くらいまで落とし込むとテストにおける制約や条件がはっきりとするのでテストのざっくり仕様を作るのが良い。まあ、○字モデルにしたら設計工程でテスト工程の設計はしておくものだが。

何れにしても、手持ちの情報でテストを考えるのではなく、立ち止まり、ちょっと考える時間を作った方が結果的に効率的に開発が進められるようになる。

誰だって行き当たりばったりで進めてバグを気絶するほど出して手戻りをして手作業でテストなんてしたくないじゃないかと思うのだが。

 

 

テスト駆動Python

テスト駆動Python