Test-Driven Development By Example (Kent Beck)

約70ページにもわたって MONEY EXAMPLE という事例が書かれています。あまりに多いので一気に読むのはちょっと辛いですが、テストドリブンを夢見てがんばって読んでいます。今回はテストドリブンの序盤となる部分をyんでみました。

実装の前にテストをすべて書くのは無理

MONEY EXAMPLE のところを見ると、 Kent Beck ですら最初にすべてのコードを書かないということがわかります。 MONEY EXAMPLE で取り上げられている単純な金額の掛け算でも、コードが徐々に完成していくのにつれてテストコードも変わっていきます。よく、最初にテストコードを書くなんて無理だからテスト駆動開発は無理だという人がいますが、テスト駆動とはそういうことではないんですね。

MONEY EXAMPLE では、存在しないクラスを使ってテストを書き始めます。 Red どころかコンパイルすらできないテストを書くところから始めています。必要なクラスを考えてクラスのテストから書き始めるのかと思いましたがそうではありませんでした。最後の理想形をテストに書いていました。

テストドリブンの手順

ToDo の整理をしてからテストを始めます。この ToDo List はコードが完成するまでついて回ります。載っている事例では、存在しない Dollar クラスを使ってテストを書くところから始めています。そしてテストを通してできるクラスのメソッドは(最初は)あくまでスタブです。

MONEY EXAMPLE は次のようにして進めていました。

テストを書く。存在しないクラスも使ってよい。
テストをコンパイルできるようにする。
テストを Green にする。
リファクタを行い、重複を取り除く。

テストを Green にする方法

固定値を返すなどして、テストを通るようにする。 (実装コードとしては完成ではない)
明らかにわかるコードを実装する。
複数の側面からのテストを書く。 (Triangulation)

Triangulation というのは、テストケースを追加することで固定値での返り値を返せないようにするように、複数のパターンのテストを書くことで実装コードを規定していく方法です。たとえば 1 から n までの総和を求める関数があったとして、 Sum(1) == 1 だけだったら Sum の返り値は固定の 1 でもいいですが、 Sum(5) == 15 だと実装せざるを得なくなります。 Kent Beck は本当にどのようにリファクタすればよいか迷うようなときに Triangulation を使うそうです。どうすればいいのかわかっている場合は Triangulation のためのテストコードは書かれません。

MONEY EXAMPLE の中で出てきた Value Object というのも重要だと思うのでまとめておきます。

Value Object

一種のインスタンス変数で、コンストラクタで設定された値はそれ以降変わることがありません。これにより、ポインタを通じた意図しない値の書き換えの発生を防ぎます。別の言葉で書くなら副作用対策です。

Value Object の持つメソッドの戻り値は必ず新しいオブジェクトにします。下に例を書きました。 Num の add メソッドの戻り値は新しいインスタンスになっています。これにより add の前後で Num のインスタンスは変更することがありません。また、 primitive value ではないので、別途 equal メソッドを実装しておかないとテストコードを書くときに困ることがあります。

class Num
def initialize(amount)
@amount = amount
end
def get_amount
return @amount
end
def add(num)
return Num.new(get_amount + num.get_amount)
end
def equal(num)
return get_amount === num.get_amount
end
end

class Num

def initialize(amount)

@amount = amount

end

def get_amount

return @amount

end

def add(num)

return Num.new(get_amount + num.get_amount)

end

def equal(num)

return get_amount === num.get_amount

end

Test-Driven Development By Example の JAVA のコードをまねて作ったのですが、言語が ruby なので実践的には get_amount を書かずに attr_reader :amount と書きますね。

コード

(日本語) FuelPHP で使用可能なデータベース

05 de December de 2014 Kenji

Disculpa, pero esta entrada está disponible sólo en 日本語 y English.

日記・回想, 生活の知恵

雑談の仕方どうやったら雑談できるのか

30 de November de 2014 Kenji

どうやったら雑談できるのか。雑談力を上げるセミナーに行ってきました。数人での雑談を前提に、どのようにすれば雑談できるようになるのか、聞いてきたことをアウトプットします。

話のできない人の共通点

話ができない人には共通点があるそうです。

他人(ひと)の話を聴いていない
評価をやけに気にする
沈黙が嫌い

どうしよう！？っていう戸惑いが出てくるんですね。言い換えるならば、 自分がどうするのかということにフォーカスしています。つまるところ «何を話せばいいのか» というのが最大の課題になっているのではないでしょうか。私もそのひとりなのですが。

何を話せばいいのか

話すことが決まってしまえばあとは楽なんですが、話すことが決まらないからこそつらいんです。そんな課題を解決するためには、考え方を変えましょう。

知りたいことを聴く

相手について「もっと知りたい」と思うことを聴きましょう。自分が話さなくてもいいんです。これで、話のスタートができますね。

トップ営業マンと言われる人たちに共通していえるのも、知りたいことを聴いているということです。知りたいことを聴くと他の人が知らないことも知ることができるようになり、営業成績につながっていくそうです。

雑談の聴き方

さて、話のスタートはできるようになりましたが、どうやって聴けばいいんでしょうか。 聴き方 にもコツがあります。

相手がどんなことを考えているか、想像しながら聴く。
他人のいいところを見つけるつもりで聴く。

この中に「相手の言っていることを正確に聞き取る」なんてことは入っていません。言葉や文字ではないんですね。私は過去に営業部の課長から「言っていることをそのまま聴くんじゃなくて、相手の意図することは何かを考えて聴け」と言われたことがあります。

雑談をする上でまず大切なのは、「相手がどんなことを考えているか、想像しながら聴く」ことです。相手と同じ視点に立つことで、相手の言っていることも理解しやすくなり、共感しやすくなるんですね。

また、いいところを見つける習慣をつけておけば、挨拶として使うこともできるようになるのでおすすめです。

相手の話に興味が持てない時は、自分にもメリットのある話だと思って聴くのがいいそうです。

行動で雑談を楽しくする

雑談を更に面白くする方法があります。雑談といっても文字で書かれた文章とは違って、その場で表現されるわけですから、視覚的な要素も重要になってきます。方法を2つ紹介します。

相手が見たい顔をする

相手が見たい顔ってどんな顔でしょう。それは笑顔です。あたりまえですけれど、今一度考えてみましょう。挨拶するとき、話をするとき、相手が笑顔だったら話しやすくなりませんか？こちらが笑顔でいることで相手も話しやすくなり、円滑に話ができるようになります。

聴いていることをアピールする

相槌(あいづち)をする、頷く、(声を出して)笑う、アイコンタクトをする、そういったアクションを起こすことで相手の話を聞いていることをアピールできます。自分の話を聞いてもらえていることがわかれば、相手も話しやすくなります。雑談の中での沈黙を避けるためにもうまく使っていきたいですね。

これは講師から聞いた話ですが、過去にディズニーのキャストをしていた人のリアクションは «そこまでやる！？» と思うほどのオーバーリアクションだったそうです。でもやりすぎってことはないそうです。特にパーティーの席や合コンなどではそこまでやらないと埋もれてしまいますね。

こういったことは反応心理学として研究もされています。

以上、セミナーの内容をまとめてみました。

読書

テスト駆動開発の基本とメリット

23 de November de 2014 Kenji

同僚の勧めで Test-Driven Development By Example を読むことにしました。書いたのはあの Kent Beck です。日本語のものもあるのですが、そちらは絶版になっているので買うなら中古です。

この本では具体例が示されていて、どのようにテストができていきどのようにコードができていくのかがよくわかります。まだ最初のほうしか読んでいませんが、他人(Kent Beck)のテストの書き方がわかるので、自分のやり方を見直すよい機会になります。

Test Driven の基本

Preface のところに Test Driven の基本ルールが書いてあります。

自動テストに失敗するまで新しいコードを書かない。
重複は排除する。

テストで失敗するまでコードを書いてはいけません。これに関連してよくはまる落とし穴に、「テストコードのテストコードを書く必要はないのか」というのがあります。これについて同僚は次のような説明をしてくれました。

自動テストがないときはどうやってテストしていましたか？ (PHPの場合) var_dump などでテストをしていたと思います。テストコードのテストコードというのは、その var_dump と目視のテストを書くってことと同じことなんですよ。テストコードそのものの正しさは開発者が担保するようにして進めるんです。

わかったようなわからないような説明かもしれませんが、要するにそんなこと言っていたらきりがないからテストコードは開発者のチェックとコードの間に入れる保険なんだと思います。またテストコードのバグについてはじゃんじゃん直していいそうです。

そして Kent Beck はコードの書き方について重要な方針を書いています。

自分の書いたコードのテストは自分で書こう

これ重要ですね。この本をバイブルってことにしておけば、自分で書いたコードのテストは自分で書いてくれって言えますからね。 Red / Green / Refactor の順でやろうと思ったら自分で書くしかないんですけどね。

テスト駆動・自動テストのメリット

開発現場では往々にして「自動テストなんてやって意味あるのか」「時間がかかるだけじゃないのか」という議論が勃発します。地位の高い人がそういうことを言い出すとどうしようもなくなったりします。モチベーションにも繋がるところなので自動テストのメリットを再確認しましょう。本書では social implications として4つのことが書かれているのですが、それを仕事上のメリットとして書くと次のようになります。

汚いコードの密度が減り、品質保証は受け身の仕事じゃなくて能動的な仕事になる。: 自分でコードを書くことが品質保証に繋がるので、問い合わせを受けてから手を動かすようなものではなくなります。
ドッキリするようなコードに遭遇することが減り、マネージャの見積もり精度が上がる。: 開発者のみならずマネージャにとっても嬉しいことが起こります。
技術的な会話の議題が明確になり、同僚との協力作業の効率が高まる。: 開発者の能力にもよると思いますが、書籍上ではそういうことが書かれています。
汚いコードの密度が減り、新機能の追加されたリリース可能なコードが毎日増えて顧客との関係が向上する。: 毎日というのは言い過ぎかもしれませんが、バグを見落とすことが少なくなるので新規機能の追加に集中できるようになります。

特に2番目は重要ポイントですね、テストドリブンとは関係なさそうな人にもメリットがもたらされるので。どれも理想論に見えますが、テストドリブンの目指すところは上記のメリットです。

この本を読んで今以上にテストドリブンに力を入れていこうと思いました。中にはテストを書かない人もいるのですが、具体的な進め方も書いてある本なので他人への説明も楽にできると思っています。

日記・回想

目薬に含まれる成分の効果

12 de October de 2014 Kenji