テストコードが根付かない理由を考える

オチなしで終わるかもしれない、思考整理の駄文です。
主にSIer視点

そもそもテストコードを書く意味

テストコードを書かないと、回帰試験の網羅を手動でやる羽目になるから、書いた方がいい。

こんなことは誰でも知ってるし、実感が湧かなくても理屈位は聞いてるはずだ。
なのに何故広まらないのだろうか？

アジャイル云々で色々試してみて、話をすると、「TDDないし、テストコード無いと回る訳ないじゃん」というのがアジャイルの試験なんかを作る人の共通認識。
実際それは正しくて、頻繁なリリースということは、頻繁な回帰試験を意味する。
しかも機能は イテレーション(設計＋製造＋テスト＋リリースまでの一連の流れをアジャイルではイテレーションという1週間～3週間程度の期間で行う) を行うたびにその量は増えていく。

要するにアジャイルをしようと思ったら、書かないと近い将来で破綻する。

ではなぜ広まらないか？

アジャイル・アジャイルと叫ばれて、IPA もその事例なりなんなりを作り出しているのに、何で広まらないのだろう？
結構原因が多そうなので考えつくまま列挙してみる

• 結局手動で網羅させられる
• 手でやった方が早い
• 品質会計ツールに乗せれないじゃん？（品質基準を図れない）

何てのがよく聞く問題なのだけど、この根本はどこにあるのだろう？

現場から考える

手でやった方が早い

は非常によく聞く。
というかテストコードを書きたがらない人は大体言う。

こんな感じの人のコードを見ると、確かにテストが書けないことに気づく。

• メソッドの中で複数の分岐があり、テストコードのパターンが多くなる
• クラスをコールしても、メソッドの中でインスタンス生成するとか、ベットリ構造で結局その先を踏まえた網羅テストを書くハメになる
• データベースのレコード状態までセットアップが必要になってる

なるほどこりゃ書けんわ。 そりゃ手でやった方が早いと思うよ。

単体テストを綺麗に書こうと思ったら、オブジェクト指向も含む各種原理原則を守らないと、地獄を見る。
この辺のテストで関わるのは

• 単一責務の原則
  オブジェクトのなすべきことは、原則的に一つであるべきである。という原則。
  テストを書く場合も、これが守られてないと、テストしなければならないパターンが圧倒的に増える。
• DRY原則 DontRepeatYourself 同じことを二度するなの原則。
  二度するなら、メソッド化できる（二度あることは三度ある）ので、そうして名前を付ければ、つまりその部分は意味のある小さな論理単位になっていると言う事。
  モノが小さくなれば、テストが書きやすくなる。
• YAGNI
  You Aren't Gonna Need It. 「それはきっと必要にならない」XP でよく言われる原則。 「先を見越して作れ」とはSIerに入って最初に聞く話だけど、そうして作った拡張性をそのまま使ったことが何回ある？ 結局コストがかかるなら、そんなの考えず、最小の仕様を小さく作るべきだという原則。
  小さければ小さいほど…（以下略
• 抽象 処理単位に概念と名前を付けること。
  特に可読性回りでは重要になるうえ、この抽象の単位がメソッドだったりクラスだっり…
  これが守られないと、何でも1メソッドに詰め込む実装が増える。
• カプセル化 データとロジックを意味のある単位（抽象単位）で名前を付けてグルーピングすること。
• 参照の一点性 モジュール内で宣言・定義されるのは一度のみであること。
  変数にして、値を変更しながら処理すると、どこでどう変わってるか制御できなくなる。 要するに、一度値を決めたら二度と値を変えないこと、定数を使う事。 現実問題、ループ変数を除いて、変数なんて一切なくても Web 系のロジックは成立することが殆ど。 変数が必要になるというのは、その変数の寿命の間というのは何かしら意味のあるロジックの単位のハズで、メソッド化することで変数の寿命を局所化できる。 言い方を変えると、論理ロジックの単位がこれで決まると言う事。（しかもそこそこ小さい単位で）

要するに個別にシンプルにできてない(KISS原則: Keep It Simple Stupid. シンプルにしろバカ というそのまんまな原則)。 この辺はプリンシプル・オブ・プログラミングを読んでほしい。

プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則

下位のクラスやモジュールまで全部遡ってテストデータを用意する場合、セットアップ過多になる。

qiita.com

tracpath.com

単体テストを書くには、単体テストが書ける様に設計しないといけないわけで…て考えたら派生。

結構その辺は語られてるのだけど、それでもそうなるのは何故なんだろう？
設計スキルがない？それもあると思うけど、それしか設計を知らない？

いやそもそも現場の問題だけなのか？

何か原因が根深くなってきたぞ

設計書がオブジェクト指向じゃない

つまりこれが原因か？
でもふとここから苦い思い出が出てくる。

新卒で業務についたとき、設計で僕は UML を書こうとしたんだ。
UMTP L1 も取得してたし、これで設計するものと思ってたが、直後に否定された。

「お前設計したことないのか？」

いやあるよUMLでですけど。
とはいえ、そこで教え込まれたのが Excel 仕様書だ(フ●ック！神ExcelですよExcel方眼紙ですよ。近年　Fu●kcel と言うに至った最初の一歩ですよ)

Excel 仕様書は、要するにロジックごとにシート別に書く羽目になるわけで、 メソッド分けをしようと思えば、Excelシートをメチャメチャ増やさないといけない 。
マウスとキーボードでそれを操作していると目が虚ろになりますよねぇ？
クラス設計なんてしようものなら、Excelファイルの数が増える。

クラス爆発（原理主義に走ってクラス設計した挙句、クラス数が数千に突入する状況）でなくても Excel は爆発する。

そうなるとどうなるか？1枚のシートにダラダラと手続きを書くハメになる。
実装時に変えればいいじゃない？やれば「仕様書に無いことするな」とWF特融のお叱りが飛ぶ。

Excel仕様書を止めたい

非常に多くのエンジニアはそう叫びたい。
というか実際叫んでる。

ではなぜ止めれないのか？

現場でやり方を変えるとしたとき、組織はそのやり方に対する評価基準を持ってない…要するに認められない。
現場だけ見ても「なぜなに」してたら一つの結論が出てきそう

一つの結論？

現場から遡って考えると、「技術や手法の進化に対して評価を行うための基盤が組織に無ければ無理」
やるなら改革しないとダメでFA?

品質管理グループが社内にいて、それが正しく権限を持っていて、そこと連携できるのならワンチャンあるのだろうか？

品質保証部門とアジャイル開発推進部門が一緒に歩んだアジャイル開発導入

現場は現場で問題ですわ…単体テストをコードで書くための「設計」ができる人材が驚くほど不足してるので、その教育もさることながら、Excel仕様書みたいに手続きに特化しすぎた設計書以外でも設計と認める組織の柔軟性がなければ成立しない。

ケツに火がついてどうしてもとなればやるんだろうけど

コメント欄で意見求む。