単体テストと理想のサイクル

最近、社内で単体テストについて話題となり、
過去の資料をあさってみました。

eXtreme Programming の白本を読んでから
単体テストにハマり、取り組みはじめてから20年弱くらいでしょうか。
2002年の資料に久しぶりに再開し、少し感動してしまいました。

取組み始めた当初はテクニック的な内容が多いですが、
徐々に考え方的な内容が盛り込まれているようです。

そこで、いま資料を作成するなら、
何を伝える資料に仕立てるか？！

と考えてみました。

リボンモデルと同じで単体テストを中心としたサイクル
ですね。

単体テスト以外（結合テストなど)で検出された不具合、
及び危険性のある構造を発見した際に
それらの再発防止の為に、単体テストに引き上げる
単体テストに引き上げる為にリファクタリングする
というサイクルです。

リファクタリングは構造を良くしていく為、
良い構造を維持する為、という事は比較的言及されている気はしますが、
継続的に単体テストに引き上げる（より上流工程で検出可能にする）
事は、あまり言及されていない気がします。

良い構造にする為の1つの例でしか無いのですが、
常に単体テストで検出可能に出来るか？！
と問い続ける事は、とても重要なポイントだと思っています。

曖昧な表現と事実とデバッグ

問題表現も改善成果の表現も事実を示す事が重要です。
ですが、なかなか事実が表現出来ません...

「多い」、「少ない」、「増える」、「減る」、「早く」、「遅い」
などは、当たり前ですが曖昧な表現ですね。

「多い」であれば、
具体的にどのくらい多いのかを明確に示す為に数値を入れる。
更に何に対して多いのかを明確にする。
こうする事で、誰もが同じ認識となる事実として表現される。

これも当たり前な事だとは思いますが、

意識しないと、問題提起や改善成果の表現は
ついつい曖昧な表現になってしまいます。

癖ですかね...

今は、2段階で変換しています。

まずは曖昧表現で見える化し、

自分で「具体的に！」とツッコミを入れて数値を入れる。

ソフトウェア開発（特に受託開発）では、

事実を意識する機会が少ないのが原因かと思っていたのですが、

考えてみると、デバッグ時は発生する環境や症状、その時の状態

など、事実を集めて原因を突き止めます。

つまり、事実を意識しています。

新人さんがベテランに「たまにエラーとなります」

などと報告すると、
「”たまに”ってどういう事？」
「エラーってどんなエラー？」
と突っ込まれる光景は良くありますよね。

まさに曖昧表現を無くすように指導していきます。

となると、ベテランは曖昧表現などしない筈！

ですが、問題表現となると別なようです。

私含めて、曖昧な表現だらけ....

なぜでしょうね？？？

なぜかは、分かりませんが、

癖では無く、出来る筈！　ですね。