テストって、なんの為に書くんだろう。
さて。
昨日の勉強会で、皆さんに伺った訳ですが。
オイラの頭に、強烈に残ったのが、
- カバレッジは100%で有る必要は無い
- 正常系のテストだけで(も)イイ
- 開発の為のテストだから
って云う事なんだけれども。
まあ、「検証が行われているかどうかテストするとして」->「そも、検証が行われているかどうかのテストなんて、必要ないんじゃね?(validater信じればいいんじゃね?)」->「それじゃあ、カバレッジは100%いかないんじゃね?」->「カバレッジが100%必要になることなんて、人の命が懸かっている時とかの、よっぽどクリティカルな場合だけじゃね?」「正常動作するロジック作って、リファクタリングする上で、正常動作することを維持しているかを確認する為だから(超意訳 by オイラ)」という流れで。
アレ? アレ?
...じゃあ、テストって、なんの為に書くの?
まあ、当然のことながら、「期待している通りの動作をしているかどうかの確認」なんだと思うんだけど。
じゃあ、「テスト・ファースト」って、なに?
「まず、期待している結果を用意して、その期待通りに動作するロジックを実装する」っていうことでイイのかな? かな?
じゃあ、その辺を踏まえて。
某かのプロジェクトを作成する時に、クライアント(発注元)から、何から何まで事細かく設定していて、しかも解りやすく書いてある仕様書を提示して頂けるような、そんな幸運なことなんて、ほとんどないと思うんだけどwww
まあ、オイラは、デベロッパ業界で生きてきた訳じゃないから、その当たりがどうなのかは知らないんだけど;-p
むしろ、クライアントに作ってくれといわれることは、あるかも知れないけど。泣けるねwww
しかも、その初期段階の仕様が、プロジェクトの完了まで、変更が無いことなんて、まず、有り得ないと思うんだけどwww
ということは、スタートアップ時点で、そんな詳細な決定仕様の必要性なんて、全くない訳で。
そのプロジェクトのゴールがどこにあるか、経由地点がどこなのか、何に乗っていくのか、とか、そんな大まかなものがあれば、十分なんじゃないかな、と。
それこそ、インデント・レベルが二つか三つのところまであれば、十分なんじゃないのかな、と。
でも、プロジェクトが完了して、受け渡す時点で、その仕様は、微細に至るまで、表されていないとマズいよね?
だって、オイラがクライアント側の担当者だったら、絶対に云うもん。
「じゃあ、取り扱うデータに関しては、全ての項目において、正常値と異常値を書いて。フォームの入力項目が正常な場合の画面遷移と、異常値な場合の画面遷移も。もちろん、正常値と異常値のどちらとも、サンプルを用いてテストして、その結果を出してね(ﾃﾍｯ♡)」って。
いやぁ、根性悪いクライアントだよねぇ?www
でも、これがないと、お金を払うことが出来ないんだよねぇ。
だって、クライアント側では、そのコードの中を見ない限り、何がどう動作しているのか、把握することが出来ないから。
どう動作しているのか解らない = 動作の保証が無いものを、「有り難う御座居ました」なんていって受け取っちゃって、お金払って、そんで、何かのトラブルが起こった場合は、もう、それは、既に、クライアント側の責任になっちゃうから。
デベロッパー側にしてみれば、「えっ? だって、ご確認頂いた上で、ご了承頂いたから、料金頂けたんですよね?」って話になるよね? つうか、するよね?
素晴らしい逃げ口上wwwww
で、そんな泥仕合、やりたくも無いし。
受注者側としても、信用問題にもなってくるし。
で。
- 詳細な仕様書を初期段階で用意することは不可能
- 詳細な仕様書はいずれ必要
- その仕様に対する動作確認も必要
- プロジェクトの完了段階で、一から最終的な仕様書を興すなんてクソッタレな事やりたくねぇー
- プロジェクトの完了段階で、一からテスト回すなんて事ファック・オフっ!
と相成る訳で。
それに加えて、
ということで。
やっぱり、オイラは、カバレッジが100%になるように、事細かにテストを書きますわ。
まず、テストを書いてから、コードを書きますな。
それこそ、モデルにvalidate_hogehogeを書く前に、it "is hogehoge" do ~を書きますわ。
オイラが頭に立って、チームを組んで、某かのプロジェクトを立ち上げることになったら、そのお仲間さん達には、そうさせます。
だって、その方が、多分、結果的に楽だもん。
確実に、確実性が高くなるし。
ということで、オイラは。
「設計書兼仕様書 with サンプルによるテスト結果」として、テスト(== spec)を書きますわ。
ハイ。
