破り捨てろお絵かきロジック
この世界でPGなりSEなりを生業にしているモノならば、最低一度は見たり読んだり書いたりしたことがあると思います。無いとは言わせねぇ。何？無い？帰れ帰れ！！冷やかしはお断りだよっ！！あっちおいき！母さん塩撒いておくれ塩！！
何屋なんだそこは。ソフト屋か。
ついつい小ネタを挟もうとして暴走する、そんな私がだーい好き。死んでこい＞俺。そんなこたぁともかく。
大抵どこのプロジェクトでも（大小問わず）、「単体試験票」みたいなものを作って、それに基づいて単体テストを行うじゃないですか。まぁ名前とかはどうでもいいんですけど。
で、何分単体試験の場合件数がハンパじゃない（ちょっと規模が大きくなれば1000件2000件はザラ）と。チェックリスト作るにしたって、１行１行細かく書いてたら、それこそ時間がいくらあっても足らないと。ただでさえコーディング作業進んでないのにそんなことやってられっかー！と逆ギレすることも多い昨今。
となれば、ちょっとでもチェックリスト作成する手間を省こうということで、人は自ずとこんな試験票を作ることになる訳で。以下その一例。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 A=1 ○ ○ ○ ○ ○ ○ ○ ○ ○ A=2 ○ ○ ○ ○ ○ ○ ○ ○ ○ B=1 ○ ○ ○ ○ ○ ○ B=2 ○ ○ ○ ○ ○ ○ B=3 ○ ○ ○ ○ ○ ○ C=1 ○ ○ ○ ○ ○ ○ C=2 ○ ○ ○ ○ ○ ○ C=3 ○ ○ ○ ○ ○ ○ 結果 X=1 X=2 ○ ○ ○ X=3 ○ ○ ○ ○ ○ X=4 ○ ○ ○ ○ ○ ○ X=5 ○ ○ ○ ○ Y=1 ○ ○ ○ ○ ○ ○ ○ ○ ○ Y=2 ○ ○ ○ ○ ○ ○ Y=3 ○ ○ ○ テキストブラウザとかでお読みの皆さん、いきなりワケワカラン文字列が続いてスマン（笑）。これテーブルなの。後で別途ブラウザで見直してくれぇ。
という訳でこんな感じになりますよね。横に起こりえるテストケースとその結果を、縦にその組み合わせを並べて、１枚で何パターンも表現できるようにする。これを基に一件ずつテストを実施し、正常終了したらその度に○を●に塗りつぶしていく・・・と。まぁプロジェクトの文化によって表現は各種あると思いますけど、基本的にはこうゆうマトリックスにおいてテストパターンを表記していくという訳で。
これを塗りつぶしていく様が似ていることから、私自身はこれを「お絵かきロジック」と呼称してるんですが皆様如何でしょう。呼びますか。呼びませんか。そうですか。しょぼーん。
いやね。これ確かに、作る側からすればラクなんよ。あるパターンが続いたらあとはコピペしつつ体裁を整えてくだけですから。なんか見た目にもいかにもテストだぞ〜的な雰囲気も漂わしてますし。
でもね。これ「ハイ」と渡されてテストする側に回ってみ？発狂するぜ、これ。
まず、いざやろうとすると、どのケースがどのパターンでどの結果が帰ってくるのか、やってるウチにどんどんワケわからんくなってくるんよマジで。私同様乱視持ちな方は強く同意してくれると思うんですが、縦と横の両方を眺めながら確かめるのってそれだけでかなりしんどいのよ。
条件を間違えないために定規を２本組み合わせて「今はこれ」ってやらなきゃ絶対にテストケース見間違えます。つーか定規使っても度々見間違える位ですから（笑）。
で、実際にテストするときにはこの手のマトリックスが１０枚、１００枚単位でドカッと手渡される訳ですから。そりゃやってるウチにどんどん頭ん中パープーになっていきますわ。テストしてるウチにそれが正しいのか間違ってるのかもごっちゃになってくるもんな。
そんなことやってる間にテスト結果見間違ったりして、合ってるのにバグだと思ったり、バグなのに見逃したり・・・なんてこともしょっちゅうありましたです。何度これに泣かされたことかのぉ。
とまぁ泣き言を言ったところで、「それがオメーの仕事だろーが」と言われてしまうと黙り込んでしまうんですが。実は見落としがちな弱点がもーいっこあるんです。ついでだから書いてしまえ。「お絵かきロジック」の欠点。
作る側にしてみたら、基本的にはラクして作りたいと。したがって、この手のパターンで試験票を書こうとした場合、必然的にカット＆ペーストの使用頻度は上がります。できるだけ共通項を見つけ出して複数範囲をコピーして、何回もペーストして・・・。
ただし。その弊害として「テストパターンそのものの間違い」てなのを作り込んでしまう場合ってのが多々存在するんですよ。極端な話、○を１列１行間違えて書いてしまうだけで、テストの条件・予想結果がてんでバラバラのものを意味してしまう訳ですから。
しかもこうゆうのって一度作ってしまうと間違いに気付きにくい。結果間違ったテストパターンを作って間違ったテストを通してそのまんま・・・あー怖い怖い。
よく「コーディングのときのカット＆ペースト厳禁！やったら殺す！３回殺す！」てなことを言うでしょ？これと全く同じことがテストケースの際も言えるんですよね。
そうなるとあんたが必死になって書き上げたそのお絵かきロジック、ホントに正しいの？ホントに意味あるの？てなことにすらなりかねないんですな。その工程自体の存在意義さえもが問われかねない、なんてことになっちゃうと。
なので私自身は、以前からこの手の表記方法には噛みついてます。見てて訳わかんねーんだよ！テスターがチェックしやすいように書けよ！と。すると今度はテストを書く人、ではなくその上司とかから文句が飛んでくると。
「ただでさえテストケース書く時間も惜しいんだから、そんな余計な手間暇かけさすな！定規あてがって見ればいいだろボケ！大体悠長な書き方されたら俺がテストケースレビューするときに枚数多くなって大変だろーが黙ってテストこなしてろ能無しが！！」
かくして三者三様の思惑は接点を見いだせないまま、力任せの非効率的かつ非人間的なテスト実施が強行される・・・という訳です。そりゃ見つかるバグも見つからなんわな。おっちゃんがっくりよ。
という訳でこの出来損ないのお絵かきロジックに関して、散々袋だたきにしてみたのです。が。
ここまで読んで「あれ？」とお思いの方は多いと思います。XPかぶれしてる方でしたら「なんでアレを出さないの？」とお思いの御仁もいらっしゃるのではないかと。
はい、↑の文章にはある視点が抜けてますよね。
「そもそもテストを目視に頼る時点で、それはダメダメなんじゃないの？」
という主張があって然るべき。
そりゃそーですわね。なんのためにTDDつー概念があるのよと。xUnitの存在はどーしたのよと。テスト自動化せずに何が品質向上だよと馬鹿なんじゃねーのアホらしすぎてヘソで茶ぁ沸かすぜわっはっはと。え？そこまでは言ってない？いいじゃん言ってくださいよそうじゃないと話進まないよ。読者に強要するな＞俺。
なんですけどねぇ。実はここに、もうひとつのショッキングな事実というのがありまして。
特にXPerな方とかは、心して次の段落を読んでください。ショックで気絶しないよーに。
世の中には、自動化されたテストを信用せず、目視・手書きでチェックされたもののみを受け入れる、という人達が存在します。
・・・・おーい、起きてる？心臓麻痺起こしてない？だいじょぶ？要は、xUnitよりもお絵かきロジックの方を信頼信用している人達ってのが、確実に存在しているという首吊りたくなるような事実です。
こんなんが上司とか、はたまた顧客にいたりすると悲惨の一言ですよ。前にこんな話を聞いたことがあります。信じられないようなこんな話。
とあるプロジェクトで、某テストツール（当時はまだxUnitのようなツールも知られてなかった）を導入して、それにテストをやらせて、自動生成されたレポートをそのまま成果物として提出したそうなのですが。
結果、全面的に受け入れ拒否されましたと。全テストを手でやり直して、通過したことを直筆でサイン入れたものを提出するように命じられたそうです。
- 目で見てナンボのテストを自動化してしまうとは何事か。テストは遊びではない。品質のことを本当に考えているのか。
- そのテストツールが絶対に大丈夫だという保証自体が無いのに、それに頼るとは何事か。人間の目にかなうものは無いのだから怠けるな。
- キレイに印刷された「テスト済」なぞ信用できない。必ず通過のチェックは検査者がペンでサインを入れて、それを提出しろ。
てのがその理由なんだって。この人達、天動説でも信じてるんですかね？ちなみにその話を教えてもらい、かつ結局全テストを手作業でやりなおしたという某氏は、その半年後にはひっそりと会社辞めてました。そりゃそーだよーなー。
信じられないでしょ？馬鹿の極みでしょ？こんなの。でも実際そうなのよ。ユニットテストの有効性効果性なんぞハナから全く無視、目で見るテストしか受け入れられない人達。
この人達に言わせればxUnitなんて自己満足のおもちゃとしか捉えられてないと思いますよ。そこまで目視を盲信しちゃってるんですよね。
さらに悪いことには、こうゆう輩が概して「３日徹夜してテストケース1000件チェックしました」みたいな脳味噌筋肉馬鹿を必要以上に高く評価したりしますからね。それこそそんな状態でやられたテスト結果なんぞ信用できるか！ホントこいつらを射殺するところから始めない限り、永遠にデジタルドカタはデジタルドカタだっつーの。死んでしまえってんだマッタク。
え？言い過ぎ？この程度でビビられてたら体持ちませんので。慣れてください。
一応言っておきますが、目視そのものをバカにする訳じゃないです。人間の目線だからこそ追っかけることのできるバグというのも確かにあります。そもそもユニットテストだけで全バグ潰せるなんて考えることだってダメダメでしょ？だからXPの場合受け入れテスト、という概念があるんでしょ？
人間の集中力なんてのは悲しい程に持たないんですよ。ヘロヘロに疲れ切った人間に目視テストなんて大事なモン任せられるか、てのが実際のところじゃないんですかね？簡単な体力勝負はツールに任せて、人間様はそれでは追いつかないような深いレアなパターンの追跡に集中する。どう考えたってそっちの方がいいに決まってるんじゃないの？
いつまで合ってるか間違ってるかも怪しいお絵かきロジックに頼りきってるんですか？そんなんでバグ潰しなんてできっこねーんだから。
そこを認めることから始めないと。闘わなくちゃ現実と。生え際の後退は食い止められなくても、プロジェクトまで後退させる訳にはいかないんじゃないです？
・・・・・一部の方に張り倒されそうなオチでスマン。