テスト駆動開発入門 の商品レビュー

ケントベック(著者),長瀬嘉秀(訳者)

2019/01/17

初版が2003年と古い事もあるかもしれないが、part1のMoneyオブジェクトをつかってのTDDの解説からとても冗長で退屈に感じる。
たぶんに観念的な表現でもあり、実践的内容がとても少ない。
TDDの本というより、Xpの本といった方がいいかもしれない。

2012/12/09

テストテストと言葉は聞くけどもテストを行うための手順や考え方がよくわからず、途方にくれていたし、テストが書かれていないプログラムで痛い目を見たので手にとった。

javaもpythonも書いたことがないので前半の書かれているコードの細かい動きはぶっちゃけ解らない。しかし細かい動きを理解する必要は無く、大まかにでもいいからコードを書く順序、考え方、安心する方法を読み取れればそれで十分。テストは本当にいいものだと実感。
1年後にもキラキラした目で開発を続けられるのならそれは理想的な環境だし、より柔軟な変更が可能になるこのテスト駆動開発は絶対に習得したい。

2012/11/23

ずばりテスト駆動開発を理解するためには必須でしょう。ペアプロしている感覚で読み進められ、「実際」を感じることが出来ると思います。また後半のパターン解説も非常にTDDへの理解を促進してくれます。

2012/11/11

TDDについて知りたくて、読んだけどちょいまだ理解が足りない気がする。またいつか読むことになるでしょうー
ただ、なんとなくはわかったから、それはよかった。
今後はここの知識をもとに実践して、またそのうち読むと良いんだと思う。

2012/09/05

JUnitの生みの親であるケント・ベックさんが書いた、テスト駆動開発に関する概要説明と、その実践方法を説明した一冊。3パートから構成される。「入門」と謳っているだけあって、TDD未経験者にとって、読みやすい内容である。

Part1は、百聞は一見に如かずということで、TDDの感触をつかみやすくするために、Javaを用いて実際にTDDしていく様子を説明している。

Part2は、Pythonを使ってテストフレームワークを作るという内容。著者自身、Pythonが初めてらしく、初物言語は必ずテストフレームワークを作って言語仕様を学ぶとのこと。

Part3は、TDDの進め方や実践方法に関するケーススタディやプラクティスを提示している。

全体的に、各章が短いのでサクサク進む。これは、だるくならずに常に新鮮な感じで本当に読みやすかった（最後の数章はちょっと眠くなったけどね！）。

さて、それぞれのパートだが、Part1は本に書いてあるとおりに、実際にコードを書いてTDDを体感して欲しい。どんなふうにTDDというものが進んでいくのか理解しやすくなると思う。

Part2は興味のある人向け。まあ今どきは、だいたいどんな言語でもxUnit系のテストフレームワークが用意されているので、改めて学ぶ必要もあるまい。Part2を読んでみて興味が出たら、自分のお気に入りの言語でテストフレームワークを実装してみるといいかも？

Part3は、TDD（だけに限らず、テスト全般）を実践する中で遭遇するであろう事象に対する、実践的な解決策を提示してくれたり、リファクタリングの考え方や、普段の開発の中ですべきプラクティスの提示、テストで使えるテストパターンやTDD習得方法を解説している。リファクタリングの章は、今までコードは書きっぱなしで終わりにしていた人にとって、とても役立つんじゃないかな。

惜しむらくは、時折言い回しがよくわからん文章がでてくることだが、この本と、アジャイルサムライの「第14章 テスト駆動開発」を読むと、TDDに関する理解がより深まる。TDDを始めてみようと思った方は、是非、両方とも手にとって読んで欲しいと思う。きっと、TDDを実践したくなるはず！

2012/08/01

TDDの基本
レッド⇒グリーン⇒レファクタリング

最初の実例はとてもわかりやすかった。
後半のパターンの話は訳が悪いのかわかりにくかった。
最終章「TDDの習得」は参考になった。そこから引用。
■不信に思う理由がなければテストすべきではない。
■テストが困難なのは設計の問題である。
などなど

2012/08/01

TDDはテスト技法ではない。分析技法および設計技法であり、実際には開発のすべてのアクティビティを構造化するための技法である。
TDDがテスト技法ではないとはいえ、TDDによりほとんどすべてのプログラマが十分とする正しさを得ることができる。（もちろん、医療や航空宇宙のソフトウェアは例外である）。

他者の実装を理解するための学習用テストや、他者に実装を説明するための説明用テストを記述し、コミュニケーションの役に立たなくなったり、不安が退屈に変わってしまったテストを削除する。

本書でTDDの進め方と本質を、著者とペアプログラミングしているように学ぶことができる。新しい言語に直面すると、自分自身で簡単な xUnit を構築することで、日々のプログラミングで使用する機能の多くの調査が済むという指摘も面白い。

ただ、残念なことにすでに多くのコードが存在するシステムにTDDを持ち込むことは、難問であるとしか言えないとのこと。TDD、テストファーストで開発できないと思われるシステムもあり、適用方法は熟慮する必要がある。
それでも議論の筋道を決めつけることなく、さまよううちに優れた考えにたどりつけるだろう。

2012/07/21

XP（エクストリーム・プログラミング）開発プラクティスの一つであるテスト駆動開発（TDD）
この本はまさにその入門書として非常に実用的である。

Part1では複数通貨の計算クラス作成をTDDで実践している。
著者も「何度も書きなおした」というとおり、あれやこれやと不安を覚える程のゆっくりとしたペースで
一つ一つとテストしては実装し、リファクタリングしてゆく。

Part2はxUnitの例ということで、
簡単なテストフレームワークをPythonで作る実践が行われている。
もちそんその開発もテスト駆動だ。
これが必要になる事は殆ど無いと思われるが、理解のためと割り切れば再開発にも価値がある。

Part3はTDDの実践におけるパターン集となっている。

自分のTDD経験は勉強会2度ほど、そのあと自習で少しといった所で、
まとまった知識を得ずに実践重視だったのだが。
この本のPart１を一度読んで、写経することで。
まるでケント・ベック氏とペアプロしているかのような感覚で、
TDDのリズムの楽しさ、テストの安心感が味わえた。
（少し言い過ぎかも知れない、でも心地よい疲労感を覚えたのは確かだ）
一つ一つのステップが小刻みなので、実習本としてとても良いと思う。

過去の実践で得られていなかった知識として、
重複を取り除くという大事な作業があった。
（フェイズとしてはリファクタリングにあたる）
DRY原則からすると当たり前過ぎて、TDDする際に忘れていた自分が間抜けなだけなのだが、
テストコード内、プロダクトコード内、そしてテストコードとプロダクトコード間で
重複しているものは、十中八九取り除くことが出来る。
（それは仮実装から本実装への変移でもある。）
TDDにおいてはリファクタリング＝改善ではなく。完成に至るまでの欠かせない作業なのだ。

本書中でいくつか興味深かった点がある。
（１）一人でプログラミングする際に、テストを失敗させて一日を終えるスタイル。
テストが失敗していれば、そのテストを通す作業に集中せざるを得ないので
迅速な再スタートが切れるという事らしい。

（２）ケント・ベック氏のご息女はTDDを最初のプログラミングスタイルとして学んだらしい。
他のプログラマーと比べてどのような思考の違いが起きているのか気になる。
壁にぶつかったりしないのだろうか。

（３）シングルトンについてばっさり切り捨てていたのは笑った。

最後に、初めてTDDの事を聞いた際は「やり過ぎではないか」等と思っていたが、
TDDはプログラマーの不安を取り除き、成果物の品質を高め、顧客に価値を与えるための良い方法だと思う。
仕事で活用するには、それ以前の能力・信頼が足りていないが、いずれ挑戦するだろう。
幸福なプログラムがあらんことを。

2012/02/04

サンプルを実装していく中で、TDDの考え方・やり方を段階的に学べるようになっており、コードを書く人には入りやすくわかりやすいと思うが、文章が読みにくい。

2012/01/22

テスト駆動開発の第一歩を踏み出せた気だけはするけれど、これ一冊読んだからといって実務で使えるかっていうと足りないように思う。