アジャイルサムライ TDDトラック行ってきた

一度は行ってみたかったTDDの勉強会にようやくいけた。

 

最初は、ちょっと初心者向け過ぎたか、と心配になったけど

自分の脳内師匠の@t_wada さんにも、色々日頃の疑問をぶつけられたので良かった。

 

新卒の時、次のステップって何だろう?って思っていた時に

 

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

  • 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/05
  • メディア: 単行本
  • 購入: 94人 クリック: 3,091回
  • この商品を含むブログ (309件) を見る
 

 に出会い、そこでJUnitとTDDに言及していたので、 

JUnitと単体テスト技法―JUnit4対応

JUnitと単体テスト技法―JUnit4対応

 

 でテスト駆動開発に遭遇。実際にやってみて、まるで自分のためにあるようなテクニックだ!と感動した。

実際のプロジェクトでのイメージ湧かなかったけど

 

アジャイルソフトウェア開発の奥義

アジャイルソフトウェア開発の奥義

 

 上記の本で何となくイメージ湧いた。2007年の2月くらいにTDDの研修立ち上げた。あまり売れなかったが。。。

ちなみに上記の本の末尾に、超重要な論文「ソースコードは設計である」が掲載されている。曰く「プログラミングは設計である。製造はビルドであり、既に完全自動化されている。」

この論文読んで以降、プログラミングというプロセスをなくそうとする試みには自信をもって「失敗する!」って断言できるようになった。(例外はルールエンジン)

 

今では、実践者の話がきけるくらいメジャーになったけど、大規模ではまだまだだなあ。なぜ流行らないのか、理解に苦しむ。。。

 

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

 

 

以下、備忘録

・最初にレッド、仮コードはテストコードの品質を高めるため。

➡これはかなり自分の実感とも合う。

・階段をあがるように、テストを書きながら開発して行く中で、重複した無駄なケースは早めに削除していく。メソッド毎のカバレッジを出力させて、ホワイトボックスの観点から無駄なケースは洗い出すことも自分でツールつくれば可能。(By @t_wada さん)

・モックは個人のスタイルもあると思うが、自分はあまり使わない。モックと実コードの齟齬が起きてしまう可能性もあるので。DBアクセスも実際にアクセスしたテストにしてしまう。スローではあるが、効果的。(By @t_wada さん)

⬅インタラクションの設計過程でモックを使い、実コードができればテストを捨ててしまうのは?(By 自分)

・いいと思う。

 

@t_wadaさんはモックそのものを完全否定しているわけではなく、@t_wadaさんのスタイルとスキルでは、あまり利用しなくても問題ない、というように理解した。唯一フル活用するのは、外部サービス連携など、だそう。

 

DBアクセスするテストコードには、スローテストの問題がつきまとうけど、@t_wadaさんは無駄なテストケースを削除し、価値あるテストケースのみ残していくプロセスを組み入れているので、大きな問題にならないのだと思った。

これは自分の実感とも合う。

 

あと、今回のプロジェクトでチャレンジしたgroovyとSpock,採用断念したGebについても、色々質問、相談できたので、非常に有意義だった。

 

 次は2Hくらいつかってもいいので、BDDのペアプロみたいかも。