極力ユニットテストを書ないなんて・・・この方法は果たしてうまくいくのかなぁ・・・やってみよう。
u2uniは「ユニットテストをやる夫」です。出来る限りユニットテストを記述します。
そうしないと、過去に作成した機能を拡張するときに、互換性を保てなくなる、というのが理由です。
この話をすると必ず「ユニットテストを書かない派」からは
「オーバーロードって知ってる？」
「継承って知ってる？」
「工数がかかる」
「仕様書をしっかり書けばいい」
などと反論されます。ま、こういう人に限って、
「この不具合は俺のせいじゃないんだ」
って言うんですけどね。そんなときに出会ったのがこのエントリです。
極力ユニットテストを書かずに品質を確保する方法 - ひがやすをblog
ここでは、「バグは偏在(偏って存在)する」という前提に立ち、先に機能を実装して、ユーザに動かしてもらうことをユーザの要件が固まるまで繰り返し行い、そのあと、保守目的のドキュメントの一つとしてテストシナリオを作成し、そのテスト中にバグが発見されてからその周辺のユニットテストを記述する、という方法を提案されています。
ただ、機能の実装が終わった時点で、単体としては、「ほぼ完成」しているのであって、その後のテストシナリオで不具合が出てからユニットテストを記述する、というように読み取れます。
保守目的のドキュメントとしてユニットテストを記述するって、「ユニットテストを書かない派」からは受入れられないように感じます。
ただ、「将来にわたって互換性を保つ」目的というのは果たしているわけで。
う〜ん、やってみないとわからないか・・・
参考：こちらに有名なエントリ、論理的思考の放棄 - 登 大遊＠筑波大学情報学類の SoftEther VPN 日記があります。この筆者は、
と述べられていて、興味深く拝見した。ただ、u2uniにはコレは無理だ。できそうにない。
論理的な思考を捨て、頭を使わずに感覚だけでコーディングすることが大事。私はこのことを実践し、1 日に少なくとも 3,000 行程度、多く書くときで 10,000 行以上のプログラムを書くことが出来たし、発生するバグの数を極めて少なく保つことにも成功している。
