クリプキクローネ日記帳

ある種の音楽と数学とランニングはミニマルなところが似ていると思う。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

実践テスト駆動開発 [Steve Freeman, Nat Pryce(著), 和智右桂, 高木正弘(訳)] (翔泳社)

テスト駆動開発(TDD:Test-Driven Development)についての本です。
TDDって単にテストケースを先に作りますよっていう方法論だけかと思っていたら、
それに特化したフレームワークがあるんですね。
つまりそのフレームワークを使うのであれば、プロジェクトの最初の段階でTDDやるぞって決めておかないといけないんですね。
やったことないので気持ち的にハードルが高いです。

フレームワークは使わないで単にテストケースを先に作るっていうだけの進め方でも
一定の効果はあるんじゃないかと思いますが、よく分かりません。
TDDの歴史のところに出てくるように「テストのためのゲッター関数ばかりになる」っていうのが問題なんだろうと思います。

ちなみに途中でオークションシステムのプロジェクトの具体例が140ページくらい続くんですが、
話題が細かくてつい流し読みしてしまいました。
というわけでちゃんと読んでないのに本の感想を書いています。


途中まではモックってただのスタブのことじゃないの?と思いながら読んでいました。
関数呼び出しの上下関係ではなくオブジェクト間の横の関係であるということと、
エクスペクテーションの記述まで考慮されたフレームワークになっている、というあたりが単なるスタブとは違うのだろうと思います。

何度か出てくる「ドメイン型は文字列より優れている」は感覚的にも正しい気がします。
なんでもかんでもクラスにすると重くなるなぁ、とつい思ってしまうけど。

データベース周辺のテストはなかなか大変そうです。
さらに大変そうなのはマルチスレッドのテストで、これは結局解が見えないまま終わってしまいました。
いろいろ提案されているけど、実際やり始めたらかなり大変だろうだなと思います。
結局システムテスト的になってきてしまって、単体テストらしくコンパクトにならなそう。

テストケースを早い段階で作るとどうしてもその後で実装が変わってテストケース作り直し、
みたいになってしまうことが多いのですが、「見るべきところだけ見る」っていう方針で少しは二度手間が減るのかなと思いました。
テストするとつい関係ないパラメータまで判定したくなって、結果として変更に弱くなるので。
それでも実装前にテストを作るのはやっぱりすごいなぁ。

あとテストから作ると実装がキレイになるっていうのも正にその通りだろうなという気がします。

そういうわけでTDDのメリットはなんとなく分かりましたが、
実際に適用するにはかなりの経験と信念が要求されそうです。
すでにTDDでガンガン回ってるプロジェクトにひょこっと入ってみたい。
  1. 2017/02/12(日) 21:09:29|
  2. | トラックバック:0
  3. | コメント:0
<<マルチコアCPUのための並列プログラミング[安田 絹子、他(著)] (秀和システム) | ホーム | SPINモデル検査 検証モデリング技法 [中島震(著)] (近代科学者)>>

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://myumbrella.blog42.fc2.com/tb.php/348-c06eaf0b
この記事にトラックバックする(FC2ブログユーザー)
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。