『xUTP Magazine』、略して『ぺけま』は、xUTP読書会の有志による xUnitester の xUnitester による、xUnitester とそうでない人のためのウェブ雑誌です。
次号は2012年7月頃を予定しています。
未☆定
記事へのご意見、ご感想や、「こんな記事が読みたい」、「あの人の記事が読みたい」、といったご希望などがありましたら、お気軽にお問い合わせください。
記事の投稿も随時受け付けております。また、編集に参加したいというお申し出も大歓迎です。
連絡先:devtesting-ja_at_googlegroups.com
]]>書いた人:@yujiorama(id:yujiorama)
先日の JaSST‘12 Tokyo にて、TDD 守破離という、様々な形の TDD を Live でお見せするというセッション が行われました。それにあやかり、今回は TDD 序破 Q として TDD をお見せしたいと思います。
このような書き出しから始まる、@pocketberserkerさんによる TDD の実演レポートです。
JaSST '12 では TDD研究会 によるセッション「TDD 守破離」がありました(発表資料)。
このレポートでは、シンプルな Key Value Store をテーマとして、プロダクトコードを Java、テストコードを Groovy で書いています。 利用されているテスティングフレームワークは Spock です。 フレームワークの使い方や開発の進め方について参考になるものと思います。
TDD序破Q:http://pocketberserker.github.com/tdd_jo_ha_q/
ご意見、ご感想をいただけると、著者の人が喜びますので、どうぞよろしくお願いします。
]]>書いた人:@yujiorama(id:yujiorama)
この連載記事の目的は次のような感じです。
英語の壁も、難しさの壁も、読書会の有志による努力によって取り払われました。
軽い気持ちで、xUnit Test Patterns に挑戦してみましょう。
xUnit Test Patterns(以下 xUTP) では、ソフトウェア開発全体におけるテストの在り方や考え方について説明されています。
今回は、開発を進めていく中でよく遭遇するアンチパターンである、「テストの匂い」についてご紹介します。
xUTP 読書会 Wiki で該当するページは次のとおりです。
「匂い」とは、問題が発生する兆候のことです(Part1 Chapter 2 Test Smells - What's a Test Smells?)。
"リファクタリング"では、「コードの不吉な匂い」としてプロダクションコードで見つかる問題に注目しています。 xUTP の著者は、テストコードにおいても同様の問題があるのではないかと考えていたそうです。
その後、XP2001 で"Refactoring Test Code"というテストコードに固有の問題 (テストコードの不吉な匂い) や解決方法 (テストのリファクタリング) についての発表があったようです。 (ちなみに、著者は同じセッションで"Increasing the Effecctiveness of Automated Testing"というテストの効率化についての発表をしていました。)
xUTP では、これらの知見を元に整理された「テストコードの不吉な匂い」を紹介しています。
テストコードの匂いは、リファクタリングで紹介された「コードの不吉な匂い」を、テストコードに適用したものです(Part1 Chapter 2. Test Smells - The Code Smells)。
振る舞いの匂いは、テストが失敗する兆しや、そうなりやすいテストの特徴について説明したものです(Part1 Chapter 2. Test Smells - The Behavior Smells)。
プロジェクトの匂いは、テストコードの匂いや振る舞いの匂いの組み合わせによって、プロジェクトの支えとなるべき自動テストがうまく働かないことの兆しなどを説明したものです(Part1 Chapter2. Test Smells - The Project Smells)。
以下の文章では xUTP の記載を抜粋して紹介していますが、リファクタリングやRefactoring Test Code(XP2001)を参照しているものは、その旨を記載するようにしました。
ざっくりと見回しただけですが、原文ではそれぞれの「匂い」について、症状・影響・原因・解決方法を 1 セットとして解説しています。 詳しくは原文か、xUTP 読書会 Wiki の該当ページを参照してみてください。
テストがどんな振る舞いを検証してるのか理解するのが困難になっている。
ドキュメントとしてのテストにほど遠い状態だし、メンテナンスにかかるコストがとても高くなる。
テストコードの中にバグが隠れやすくなってしまう。
テストの実行結果は普通なのに、テストメソッドの中の制御構造が複雑で、どのパスが実行されてるのか分からない。
テストコード自体が複雑になっており、プロダクションコードにバグがあったとして、それが意図したように検出できるか分からない。
自動テストを書くのが困難なコード。
GUI コンポーネントやマルチスレッドのコード、テストコードから参照できないコードや、他のコードへの依存が深すぎてテストコードをコンパイルできないなどの原因がある。
自動テストによる検証ができないので手動で検証するしかないため、コードの改修を確認するなどのプロセスがスケールしない。
テストコードのあちこちに、同じ内容が書かれている。
テスト対象の呼び出しがコピペされてあちこちに存在するため、テスト対象のインターフェースの改修に追従すべきテストコードが多くなっていく。
プロダクションコードに、テスト時にしか実行されないロジック (内部状態にアクセスする、など) が含まれている。
バグの元になるのであまりお勧めしない。
商用環境を想定した設計になっていないコードが何らかの間違いで実行されてしまうと、深刻な問題を引き起こすことになる。
テスト失敗時にどの assertion が失敗したのかよく分からないので、開発者がテストを再現できなくてバグの修正に時間がかかってしまう。
テストが成功したり失敗したりする。
急いでるからといってテストスイートから外して後で戻し忘れてしまったり、他のテストが失敗したせいで気付かれなかったりする。
原因はいろいろあるので根が深い。
修正した箇所と無関係なはずのテストが失敗しはじめる。
時にはプロダクションコードを修正してないのに発生することもある。
テストが失敗してもメッセージから特定できないため、デバッガを使うことがしょっちゅうある。
ユニットテストの粒度が大きすぎたり、テスト自体が不足しているような場合もある。
テストのたびに何らかの手作業が必要になっていて、めったにテストが実行されない。
テストの自働化ができない。
テストの実行に時間がかかる。
自動化テストがうまくいってないことを示す兆し。
テスト対象のコードは正しいとしか思えないのにテストが失敗する。 (false positive、偽陽性)
テストコードにバグがあって、プロダクションコードのバグを見逃してしまう。 (false negative、偽陰性)
開発者がテストを書いてくれず、Production Bugs に対して「テストでカバーできなかった」と言い訳する。
「テスト」という負債のため、設計を改善するためにコードを書き換えるのが危険なことになっている。
ちゃんとテストを書いているのに、新機能の開発速度が徐々に落ちていく。
コードを書いている時間の大部分を、既存のテストコードの修正に費している。
開発者が、失敗するようになったテストをテストスイートから削除している。
自動化テストを書いているのに、テストチームによるテスト、顧客によるテスト、商用環境で多くのバグが発見される。
メリハリ無く書き連ねたせいで、「匂い」間の関連性は表現できませんでした。 関連性とは、Code Smells や Behavior Smells を放置すると Project Smells の原因となる、といったことです。
Project Smells が感じられるということは、それだけ根が深い問題なのかもしれません。 自分たちの身の回りを見直す際の観点として利用してみてはいかがでしょうか。
]]>『xUTP Magazine』、略して『ぺけま』は、xUTP読書会の有志による xUnitester の xUnitester による、xUnitester とそうでない人のためのウェブ雑誌です。
次号は2012年2月末頃を予定しています。
未☆定
記事へのご意見、ご感想や、「こんな記事が読みたい」、「あの人の記事が読みたい」、といったご希望などがありましたら、お気軽にお問い合わせください。
記事の投稿も随時受け付けております。また、編集に参加したいというお申し出も大歓迎です。
連絡先:devtesting-ja_at_googlegroups.com
]]>TDDBC(TDD Boot Camp)は、ご存知のとおり TDD に興味を持っている方を対象とした、新兵訓練のようなイベントです。
一言で言えば、講演で TDD のいろはを学び、ペアプログラミングで TDD を実践し、コードレビューによって新しい気付きを得る、といったものです。
個人的に 2011 年は TDD Boot Camp が盛んに行われている印象があったので{{fn('2010 年も北陸、名古屋、福岡といった地方 TDDBC が開催されまくった年でしたが;-)')}}、せっかくなので来年の予報をまとめておこうと思います。
突然の問い合わせに快く回答いただいた主催者の皆様、ありがとうございました。
Google Map を作成してみましたので、よろしければご覧ください。 TDDBCマップ(2012年)
地方別にまとめてみました。
しばらくはTDDの人で行こうかと思います。具体的にどう進めていくかという話もしたいですし。 また、TDDBC 長岡 0.5もそんなに離さずに実現させたいですね。この辺はNDS関係者と要相談ですね。
みなとRuby会議(仮)が落ち着いたら横浜2.0だか東京1.8だかやるつもりです。
まだ言い出しているだけで、中身はありませんがTDDBCとTDD Boost Cump 、やるつもりでいます
2012年最初のわんくま勉強会は、名古屋アジャイル勉強会及びTEF東海と3つのコミュニティが合同でお贈りする、テスト&TDDワークショップ!
3月のは三大BootCamp ではなく、SCMBCとTDDPCの連日開催の予定ですー。
三大BootCamp は僕の予想だと夏から秋かと。
明言してないせいでズルズル先延ばししちゃってる所もあって「いい加減にしろ(自分)」な気持ちもあるので、寧ろ背中蹴っ飛ばされる方がありがたいです。
3月くらいに1.0開催を計画して動いています。とりあえずは、来年1月に主要メンバーのレベルアップと岡山1.0で対応できる言語とテストフレームワークを確認するために、運営中心の0.1を開催しようかと思ってます。
佐賀でTDDPCというBCではなくこじんまりした勉強会をやってみたりしてます。ちょっとお休みしてたのでそろそろ再開したいなと思っております。
月別にまとめてみました。
2012年最初のわんくま勉強会は、名古屋アジャイル勉強会及びTEF東海と3つのコミュニティが合同でお贈りする、テスト&TDDワークショップ!
3月のは三大BootCamp ではなく、SCMBCとTDDPCの連日開催の予定ですー。三大BootCamp は僕の予想だと夏から秋かと。
3月くらいに1.0開催を計画して動いています。とりあえずは、来年1月に主要メンバーのレベルアップと岡山1.0で対応できる言語とテストフレームワークを確認するために、運営中心の0.1を開催しようかと思ってます。
佐賀でTDDPCというBCではなくこじんまりした勉強会をやってみたりしてます。ちょっとお休みしてたのでそろそろ再開したいなと思っております。
しばらくはTDDの人で行こうかと思います。具体的にどう進めていくかという話もしたいですし。 また、TDDBC 長岡 0.5もそんなに離さずに実現させたいですね。この辺はNDS関係者と要相談ですね。
明言してないせいでズルズル先延ばししちゃってる所もあって「いい加減にしろ(自分)」な気持ちもあるので、寧ろ背中蹴っ飛ばされる方がありがたいです。
みなとRuby会議(仮)が落ち着いたら横浜2.0だか東京1.8だかやるつもりです。
三大BootCamp は僕の予想だと夏から秋かと。
誤解を恐れずに言えば、TDDBC は 誰にでも開催できます!
ある程度の準備は必要ですが、始まってしまえば後は参加者が自ら Boot するための場なのですから。
よくある悩み事をリストアップしてみましょう。
どうしたらいいでしょう。Google Group の tddbc ML で経験者に聞いてみましょう。
「TDD Boot Camp のイベント設計、連絡、相談事などをするためのML」なので、ためらう要素はありません。
アーカイブと言えば、TDDBC Wiki です。過去の開催記録、お題、参加者の傾向などいろいろ書かれています。
私は、今年(2011年)の 7 月に行われた TDDBC Tokyo 1.5 から スタッフ側の立場で TDDBC に関わり始めてから、裏方としての楽しさだけでなく、参加者の皆さんが笑顔で帰っていくことができるだけの充実した時間を支えられたであろうことに、とてもとても自己満足を感じています。
即席ネットワーク環境の構築や、人の捌き方、ごみ拾い、ぺけまの宣伝などの熟練度ばかりが上がって、肝心の TDD の熟練度が上がっていないのが軽い悩み事です。
]]>goos 本とは、Growing Object-Oriented Software Guided by Testsという、テストファーストでオブジェクト指向なソフトウェア開発の本です。
和田さんの TDDBC のスライド等で紹介されているので、ご存知の方も多いかもしれません。テストするのが難しいが、実際に作るソフトウェアでは必須の技術(GUI、通信など)に対して、具体的な手法を学ぶことができます。テスト駆動開発入門で身につけたユニットテストのその先に進むことができます。
goos 本は、鈍器と呼ばれる xUTP ほどではないですが、内容のしっかりした洋書であり、一人で読みすすめるのにはかなりの忍耐とやる気が必要です。とくに Part I や Part Ⅱ のテストやオブジェクト指向に関して著者のさまざまな見解が展開されていて、設計などに関する知識を要求されます。
また、Part Ⅲ ではサンプルアプリケーションを通じて著者の考えかたや、やりかたが示されますが、この作業環境を構築するのに、テストツールを自分でビルドする必要があったりと、いくつもハードルがあります。
そんなあなたをサポートするのが goos 勉強会です。
goos 読書会は、大中さんが幹事をされている、xUTP 読書会の後続の勉強会です。日本のテスト界の大御所から学生まで、多様なメンバーが一緒に goos 本を読み、教えあいながら議論にはげんでいます。
最近はチームラボさんのオフィスをお借りして、日曜や祝日に開催しています。
だいたい 13:00 くらいに集まり、各自名札を装備したり、レッドブルを飲んだりと準備をします。会の最初には、ポジションペーパーをつかって自己紹介をします(ポジションペーパーの例)。 @yujiorama さんが実況しているのを見たことがある人もいるでしょう。自己紹介 + 近況をちょろっと添えるのが一般的です。
自己紹介がおわると、前回のつづきから議論を再開します。いままでは担当者が本の大意を訳して、コメントを添えた資料を wiki にアップしておき、それを見ながら議論をすすめてきました。さまざまな本を翻訳して出版していらっしゃる和智さんや和田さんから直々の指導を受けることができます。著者の意図についてや、他のモデルやセオリーとの比較で、熱い議論になることもよくあります。TDD をやっているメンバーで、それぞれの実例に即した情報交換もできます。
英語の本と日本語の訳を追いながらハイレベルな意見交換をしていくのはたいへん疲れます。そこで goos 読書会では休憩を大事にしていて、およそ1時間から1時間半で10〜15分程度の休憩をはさみます。幹事の大中さんは毎回違うスイーツ(それもコンビニのものではなく、有名っぽいお菓子!!)を持ってきてくれています。スイーツ男子である私にとって、これほど魅力的な勉強会はありません。スイーツやレッドブルでエネルギーを補給しながら、いままで議論していたところに関して集まって話したり、近況について雑談したりして、リフレッシュします。
一回の勉強会で休憩は2度ほどとられます。議論の進行度をみつつ、ちょうどいい時間になったら片付けをしつつ、ふりかえり(KTP)をします。
その後、希望者で近くの飲食店で懇親会をします。最近の課題を話しあったり、仕事のついて、家庭についてなど、さまざまなおしゃべりがくりひろげられます。 goos 読書会の特徴として、懇親会でも真面目な話をする場合が多いように感じますが、冗談をまじえながら、たのしくじっくりお話する、という雰囲気です。
このように、goos 勉強会では、優れたメンバーとおいしいスイーツ、たのしい懇親会を用意してあなたの参加をおまちしています。
私は、この勉強会に参加するまで Java を触ったことがありませんでした。この会に参加しだしてから テスト駆動開発入門と goos 本を写経したり、いろいろな人に教えてもらったりして、最低限の読む力をつけました(いまだに満足に書けません)。たしかに、goos 本はすべてのサンプルが Java で書かれており、説明では Java ecosystem の例を引いています。しかし wiki では用語に注をつけており、Java をバリバリ使っているメンバーから知識を得ることもできます。私は Java を勉強するためにもいい環境だと考えています。
反対に、自分は Java は使わないから関係ないや、というのは違います。この本はオブジェクト指向とデベロッパーテストに関する本なので、他の言語で開発するときにも、一般的に適用できる手法にあふれています。
英語が苦手な方も、まったく心配ありません。メンバーに開放されている wiki には担当者が日本語化したテキストが整備されています。議論の最中に訂正や補足がはいるので、原書より充実しているほどです。一人で読むと、術語を調べてでてくるのがまた英語の情報で、どんどん嫌になってしまうかもしれません。みんなで読むことで、日本語で用語や概念の解説を聞けます。
また、テキストは結構高く(3000円程度)入手も面倒ですが、電子版もあり、最悪本がなくても、wiki の訳を見ながら参加できます(だいたいの発表は本ありきで進めますが、ない人に配慮して、図をホワイトボードに書いたり、プロジェクターも利用しています)。気になるけど……という人は本なしでとりあえず遊びにきてみるのもアリです。
方々で怖いという噂がたっているようですが、怖くないです。怖くないよ!!
たしかにハードルは高いかもしれません。扱うテキストは洋書ですし、他の人の発表を聞くだけという受け身な状態では得るものは少なく、わいわいしたりするような軽い雰囲気ではありません。けれども、その分、達成感はただ参加するだけの勉強会よりもはるかに大きく、実際に得る知識も多岐にわたります。
これまで述べてきたように、テキストを読んでいくうえでは他のメンバーからの強力なバックアップがあります。回によっては振り返りセッションもあるので、途中参加でも心配ありません(たぶん振り返りセッションのスライドをもらうこともできるでしょう。wiki にも蓄積された情報があります)。
次回からは Part Ⅲ という実際に AuctionSniper という例題にそって、コードを書いていく部分になります。ちょうど切りがいいので、これまで参加を検討していた人は一度来てみてはどうでしょうか。
テストや設計というと、業務でバリバリ開発している人向けのイメージがありますが、学生の参加も歓迎しています。いまも、私ふくめ、2名の学生が定期的に出席しています。情報系の学生だとある程度大きなプログラムを書くことや、グループで課題をこなすこともあると思います。それらの場面で SCM (git などのソフトウェア構成管理)ツールやテスト駆動という手法、設計の考えかたなどを利用しない手はありません。せっかくプログラムを書くのですから、一緒に開発ツールの使い方や設計手法などを学ぶことができれば一石二鳥です。
まだ不安だ、という人にはテスト駆動開発入門の写経をおすすめします。これができれば、あなたはもう参加する資格(と義務 ;D)があります(もちろん、必須ではないですよ)。
devtesting-ja( Growing Object-Oriented Software, Guided by Tests読書会) - Google グループに参加されることをお勧めしします。次回の読書会の ATND が立つと、このメーリングリストで告知されます。
また、goos 読書会の wiki にも ATND へのリンクがあります。過去の議論についての情報もここから参照できます(一部のコンテンツを見るには、メンバー向けの認証が必要です)。
Twitter のハッシュタグは #goos_jp です。遠方や用事で参加できない場合は、ハッシュタグと wiki を追えばなんとなく分かるかもしれません。
goos 勉強会は、あなたの参加をお待ちしております。
goos読書会の次回は、2011/1/21となります。ATNDも立っています!
]]>xUnitester Hotlinks は、毎号、著名な xUnitester にインタビューを行っていこう、という企画です。
栄えある第一回のインタビューは、日本の TDD 伝道師、和田卓人さんにお願いしました。
こちらは後編となります。前編はこちら
和田卓人(わだたくと)
タワーズ・クエスト株式会社取締役社長、プログラマ、テスト駆動開発者。 学生時代にソフトウェア工学を学び、オブジェクト指向分析/設計に傾倒する。その後様々な縁に導かれソフトウェアパターンやXP(eXtreme Programming)を実践する人たちと出会い、後のテスト駆動開発の誕生を知る。テスト駆動開発に「完璧主義の呪い(完璧な設計を得るまではコードを書けないし良いシステムも出来ないという強迫観念)」を解いてもらってからは、文章を書いたり、講演を行ったり、ハンズオンイベントを開催するなどして、テスト駆動開発を広めようと努力している。今日もグリーンバンド(テスト駆動開発者の証。ボブ・マーティンが始めた)を左手に着け、テストと共にコードを書いている。
Blog:http://d.hatena.ne.jp/t-wada Twitter : @t_wada
大中 TDDBC の参加者から聞いた話で、「ウォーターフォールだとテストファーストくらいしかできないけど、設計時点でテストしやすさを意識するようになった」という話があるんですね。
おかざわさんは「プラクティスとしての TDD からは外れているんだけど、TDDBC を通じて得られるものは TDD 以外にも影響するんだな」と言っていました。和田さんは参加者から得られる感想などで印象に残ったことはありますか?
おかざわ 参加者から直接フィードバックを得られる機会はあるのかなぁと。
和田 一番多いのは Twitter とか Blog ですね。 #tddbc のタグ付きでも無しでも。あとは TDDBC でグリーンバンドを配っているじゃないですか{{fn('2010 年の TDDBC 名古屋で「テストを書くのはつらい。 Bob Martin もグリーンバンドを身につけて、自分を戒めてるんだ」というエピソードが紹介されたことから、TDDBC 参加者で共同購入する活動が始まった。')}}。参加された方が後日グリーンバンドを付けているところを見ると嬉しいですね。すごく。
みんな現場に帰ってやってるのは『レガシーコード改善ガイド』{{fn('[[http://www.amazon.co.jp/dp/47981168311/|http://www.amazon.co.jp/dp/47981168311/]]')}}の世界だったりするので、そういう現実に対する立ち向かい方も含めて、学ぶポインタになる、きっかけになるイベントとしてやっていけるといいなと思っています。
TDDBC の理念、やりたいこととしては、テスト駆動開発だけじゃなくて、ペアプログラミングと、一つの課題を他の人はどう解くのかというのを見てもらうコードレビュー。この 2 つはすごく重要かつ強力で、しかし現場ではなかなか導入されないプラクティスだと思っていて、コードレビュー、ペアプログラミングを強制的にでも体験できる場を作りたかった。
でも参加者一人一人は月曜日に現場に戻ると個人戦の世界になってしまう。 テスト駆動開発はやはり個人のプログラミングスキルだと思っているので、『テスト駆動開発入門』{{fn('[[http://www.amazon.co.jp/dp/48947171151/|http://www.amazon.co.jp/dp/48947171151/]]')}}とか『レガシーコード改善ガイド』とか、一人で成立し得るスキルとして学ぶためのきっかけを掴んでもらう場にしたいと思ってやっています。 参加後に『レガシーコード改善ガイド』とか『テスト駆動開発入門』を買って勉強していたり、グリーンバンドを左手に付けているところを見るとすごく嬉しいですね。
大中 話は変わるんですが、"Boost Camp"という話があるじゃないですか。
和田 TDDBC に参加した人が、その後でもう少し実践的なイベントをやりたい、という話ですよね。
大中 はい。
和田 札幌ですでに Web アプリを TDD でつくるという実践的なテーマをやっていて、これは東京でもやりたいと思っています。それが Boost になるかどうかは分からないですけど。
イベントとしての TDDBC についてですが、テスト駆動開発は未だに啓蒙段階だと思っています。ペアプログラミングも、TDDBC で初めてやったという方が圧倒的に多数ですしね。 TDD やペアプロの初心者の方々に体験できる場を提供するのは、Boot Camp として続けたほうがいいんじゃないかと思います。
たとえそこで僕が講演をしなくても、イベントとしての TDDBC はまだニーズがあるし、続けていけたらと思います。
その後の応用編としては、母体となるコミュニティがある場合は、そこでやれば良いのではないかと思います。
和田 TDDBC が他のイベントと違ってやや特殊なのは、プログラミング言語を跨ぐ傾向が強いところですね。実はこれは第一回から折り込み済みでやっているんです。 同じ問題を別の言語でどうやって解くのかを知ることは体験としてすごく面白いので、大事にしたいなと思っています。
和田 最近では TDDBC for <言語> も開催されていて、あれは良いところもあったし、本当は別の言語も見てもらいたいなと思うところもあって、個人的には悩ましいところです。でも、例えば「PHP のイベントだから参加した」「C++ のイベントだから参加した」という人が明らかにいるんですね。
一同 うんうん。
和田 言語しばりのほうが参加しやすい人もいるし、そこはこれからも考えていきたいなと思っています。
杉野 カフェでペアプロするとか、ちょっとしたものが欲しいですね。 勉強会をばーんと立ち上げるんじゃなくて、僕はまだ行ったことがないんですけど、Asakusa.rb{{fn ('東京下町を拠点とする地域Rubyistコミュニティ。[[http://qwik.jp/asakusarb/|http://qwik.jp/asakusarb/]]')}} みたいに、まずは定期的に集まるというような。
和田 とりあえず場だけあると。
杉野 そういうふうにやったほうが面白いんじゃないかって少し案を考えています。
和田 Boost Camp もそうやったらいいかもしれませんね。各々分かれて研鑽を積むために。 東京でまだ TDDBC に人がたくさん集まるのは、そういう「場に集まる」性質があるのかなって思います。 長く主催者がいなかったというのも関係してるのかな。
大中 TDDBC Tokyo 1.5 の主催者の大塚さん{{fn('[[http://hiroki.jp/|http://hiroki.jp/]]')}}とはどういうきっかけで?
和田 あれは、「東京で TDDBC 2 をやる企画はあるんですか?」というのを何かで聞かれたのがきっかけです。 TDDBC 東京 2 はまだ実現していないんですけど、冬か来春にやろうみたいな企画はあったんですね。 それで、「あるんだけどかなり先なんですよ」と返事をしたら、「小規模でいいからやることはできますか?」と質問されたんです。
和田 「主催者の言ったもの勝ちだからどんどんやりましょう」と話をしていたら、1.5 という謎のバージョン番号が始まったんです。
大中 TDDBC の緩い合意として、やろうとする人がいればそれを支援するよ、というのがありますが、それが伝わっているのかどうか。
和田 伝わりが甘いですかね、やっぱり。
大中 どうなんですかね。
和田 それはやはり問題点ですね。ポータル{{fn ('[[http://devtesting.jp/tddbc/|http://devtesting.jp/tddbc/]]')}}も大中さんの力でやっとできたくらいだし。 参加したいという人はいるけど、主催できると思っている人が少ないんじゃないかという思いはありますね。
大中 うーん。
和田 地方に行くと、基本的にコミュニティの大きさ自体は小さくなるので、気心が知れて勉強会をやりやすいというか、勉強会に出やすいというのはあると思うんです。 東京は圧倒的に人が多いので、むしろ分散化の傾向が強いような気がします。
大中 コミュニティとしてもそうなんですけど、都市としての規模も桁違いなので。 都市部で公的施設を押さえるとなると半年くらい前から予約が必要なんですよ。
和田 会場の問題はありますね。自社開催とか、会社を休日に貸してくださるとか、そういった支援がないと。 公的施設を借りるとなると東京は早めに準備しないといけないし、しかも料金は高い。札幌は非常に安くてびっくりしましたもん。それはあるなぁ。
そうすると、1.5 の時もそうでしたが、どこかの会社の会場を借していただいた場合には、相対的に箱は狭く小さくなるので、参加倍率はどうしても高くなってしまう。
でも、あんまり人を増やしすぎてもイベントとしての質を保ちにくいだろうなぁとも思っています。
和田 ただ、開催を焦る必要は無いとも思っていて、まだ待ってる人がたくさんいるからもっと頻繁にやらなきゃとか、そんなに思い詰めなくてもいいんじゃないかと考えています。待てないなら自分で勉強すればいいだけだし。
おかざわ 勉強というところで出てくるのが、『テスト駆動開発入門』についての評判が分かれるところがある。
和田 はい。
おかざわ 原文も独特だという。
和田 原文はかなり独特ですね。
おかざわ 2000 年くらいに出版されたんでしたっけ。
和田 2002 年くらいだったかな。{{fn ('「テスト駆動開発入門」の原著は2002年出版')}}
大中 そうですね、2002 年か2003 年か。
おかざわ やはり2010 年代の入門本が必要というか。
和田 それが goos{{fn('[[Growing Object Oriented Software Guided by Test|http://www.growing-object-oriented-software.com/]]。[[jMock|http://www.jmock.org/]] の開発者である Nat Price と Steeve Freeman による、テスト駆動開発によるシステム開発について論じた書籍')}} ですよ、という話になるとは思うんですけどね。
大中 ぺけまも元々は出版プロジェクトだったわけで。
和田 まぁね。本、本なぁ。
杉野 出版と言えば、5年ぐらい前になるんですが、Web+DB PRESS の和田さんの記事をまとめたものが出るとか出ないとかいう話が。
和田 あれは忙しすぎてまったく文章を書けなくてポシャってしまいました……。 本を書くにはものすごい集中力を必要とするので、本業をやりながらだとかなり負荷がかかりますね。 もっと Web 媒体とかで小出しにできるインフラが無いとつらいかなぁと思いました。 まあ、僕に力が無いだけなんですけど。
大中 いやいやいや。
和田 TDD のことを本に書こうとすると結構難しいんですね。 Kent Beck の TDD 本でも、「 Money とか現実には使わないよね」という意見も良く聞きます。
基本的に TDD 本は置き換え可能なパターンの話、TDD の原理・原則といったひとつひとつの所作をどうやって自分の目の前の問題に翻訳して適用していくのかという話なので。
大中 うんうん。
和田 現実の自分たちが作っている Web アプリであるとか、組み込みソフトなどで TDD をどう実践するかという話を本にしようとすると、分量としては圧倒的に増えてしまう。すると、本質的ではない記述が増えてしまうので悩ましいんです。 Maven の pom.xml を書くだとか、データベースをセットアップするだとか。
和田 TDD のエッセンスに絞って書こうとすればするほど、サンプルは小さくなる必要がある。 そのサンプルが例えばスタックとかになると、まるでオブジェクト指向を哺乳類で説明するみたいな、こんなのは現場では必要とされてない、という話になってしまう。
リアルな方向、データベースとかネットワークとかファイルとか Web とかに行こうとすると、今度はモックとかスタブの話が出てきてしまう。 そういうのは基本的に TDD の、例えば Kent Beck の本であった原則を応用して戦っていくところなんですけどね。
小さいサンプルと現実の世界を結びつけるところがミッシングリンクになっちゃっているという面はありますね。
和田 生きたサンプルとして Web で公開されているソースコードはたくさんあるし(例えばGithub とか)、洋書ではある現実に即したアプリケーションを TDD で開発するものがあります。
だから、 TDD を分かっている人は日々の開発に応用していけるけど、これから入門する人の間には大きなギャップがある、とは思います。
おかざわ この前『テスト駆動開発JavaScript』{{fn('[[http://www.amazon.co.jp/dp/4048707868/|http://www.amazon.co.jp/dp/4048707868/]]')}}って本が出ましたよね。
和田 はいはい。
おかざわ 実際のニーズとしては Java が多いんだけど、Java による TDD の本は 2002 年から出版されていないように思います。
和田 そう言われれてみればそうかなぁ。どうかなぁ。
大中 ソフトウェアテストの本で JUnit を取り上げてるっていうのは何冊かありますが。
和田 それはありますね。
大中 あと、@kanu_ さんが Togetter でまとめた「TDD の本は売れない」っていうのがありますね。{{fn('[[http://togetter.com/li/139936|http://togetter.com/li/139936]]')}}
和田 なんかそんなのありましたね。どんな結論なんでしたっけ?
大中 結局「TDD がなぜ受け入れられないか」という話になってしまってましたね。
和田 本が売れない時代なんですよね。そもそも。
和田 やはり TDD を学ぶにはプロセス、過程が大事なんです。 TDD で開発された Java のオープンソースのコードはたくさんあります。でも開発されたものを見ても TDD を学べるわけではない、というのが大きいのかなと思ってます。
僕が Web+DB PRESS でゼロから TDD で書いたのは、そういう思いがあったからなんです。
ブログの RSpec の記事{{fn('[[http://d.hatena.ne.jp/t-wada/20100228/p1|http://d.hatena.ne.jp/t-wada/20100228/p1]]')}}でもゼロから始めていて、差分をひたすら見せるというスタイルです。これも過程を追体験してもらいたいな、という思いからきています。
Web+DB PRESS の記事も、ブログに書いた RSpec の記事も、書き方のスタンスは基本的には変わらないんです。
まず、頭の中で伝えたいことのプロットを引いて、その順番になるように、一回一回シナリオごとにブランチ切りながらサンプルコードを書いてみる。 一番うまく説明できるサンプルになったとき、起点になるところから最後までを、git log とか svn log とかで一本につないで、その間の差分を diff 形式でばーっと取っていく。 そうすると基本的にコミットコメント・diff・コミットコメントという構成になるから、そのコミットで伝えたいことを本文に埋めていく。
説明したいことに対してきちんと対応付いているサンプルコードとその差分から整理する、という見せ方をすることが多いですね。
大中 関連する話なんですけど、テストを駆動させてテストを成長させていく動機付けになるのって、やっぱり Jenkins とかでテストケースが増えてるとか、カバレッジが順調に増しているとか、そういうテストが育っていることが分かる、というのがあるのかなと。
和田 テストコードを書いていくモチベーション、なるほど。
大中 紙とか文書ベースだとそういうところを見せていくのが難しいので。
和田 たしかに。
大中 例えば Jenkins とかで 100 件テストがあって 2 件 RED があったら、なんとか潰して全部 GREEN にしたい、となりますよね。
和田 TDD というものを伝えることに関して、紙の本という媒体があまり向いていない、という側面はあるかもしれません。
僕が Web+DB PRESS の Vol.35 で動画企画をやったじゃないですか。 「TDD をどういう順番でやっていて、どういうことを考えて、どういう書き順でコードを書きました、というのを動画で見てもらう」企画を立てたんですね。Vol.35 と Vol.37 で。
Vol.35 のとき{{fn('[[http://gihyo.jp/magazine/wdpress/information/2006/vol35-tdd|http://gihyo.jp/magazine/wdpress/information/2006/vol35-tdd]]')}}はスクリーンキャストを録った後で、声を別録りしたのですごい大変でした。
Vol.37 のとき{{fn('[[http://gihyo.jp/dev/serial/01/tdd|http://gihyo.jp/dev/serial/01/tdd]]')}}は、逆にしゃべりながらライブコーディングなのでミスができない一発録り、どっちもどっちで大変でした。
Vol.35 の時は映像編集の方がすごい頑張ってくださったんですけど、もう一回は難しいから Vol.37 ではしゃべりながらやることになったんです。
大中 ペアプロとか TDD とか結構デモって難しいですよね。
和田 デモは難しい。やっぱり経験とか、練習とか、度胸とか、いろいろ必要なのでやっぱり一発でデモって大変ですよ。すごく緊張します。
大中 ペアプロのデモで、ペアプロを実践している人でもうまくいかない場合がありますからね。
和田 そうですね。デモは難しい。人前でコードを書くという経験はすごい強烈なので、練習をしないで壇上に立つと頭真っ白になりがちですね。
おかざわ それのミニマムがペアプロですよね。
和田 そう。だからペアプロですら、すごく緊張する。 自分がコード書いてるところは、人に見られるものではないという感覚はすごく強い。 プライベートなものなので、それが常に見られているのはプレッシャーを感じますよね。
見られてないと人間真面目に仕事しないというところもあるので、ペアプロの経験はすごい成長の元になると思います。 講演もそうだし、ブログもそうですね。
おかざわ 和田さん自身地方で講演して回ったりとか、デブサミで発表したりというのは糧になっていますか?
和田 糧になっています。アウトプットするとインプットが増えますし、人からの反応もたくさん来ます。
おかざわ 懇親会などで直接会話された中で印象に残っているお話などありますか?
和田 福岡の主催者の @pocketberserker さんは、佐賀から名古屋に来ていて。 勉強会初参加が TDDBC 名古屋だったらしいのですけど、それがすごい強烈な体験になったと聞いています。
名古屋には関数型の人はいるし、ペアプロはやるし、夜はホテル借り切って修学旅行みたいにハッカソンやるしで。
地方の TDDBC は 2 日間コースなので、基本宿を借り切ってやるパターンが多いんですね。 そうすると、夜も普通にみんな集ってプログラミングしたりするので、2 日間構成ならではの体験ができます。 東京でもできたら面白そうですけど、そういう土地柄でもないのかなと思わなくもありません。
大中 横浜でやったときも考えたんですけど、2 日間コースだとやはり参加費とかが跳ね上がってしまうのが。 あと、土日両方やるとなると敷居が上がるというか。
和田 上がります。上がりますね。
杉野 「TDD がユーザーにとっての価値を提供できているのか実感できているか」という質問があるのですが。
和田 基本的に TDD が寄与するのは「内部の質」に関するものです。 直接お客様にフェイスするところかというと、そういうところもあるけど、それよりは、書いてきたものに対して自信を持つことができるということのほうが重要ですね。
TDD はリファクタリングが常にセットじゃないですか。 一定速度、自分達が予測できるスピードで価値を提供し続けることができるところに、お客様に対する TDD の価値があります。
基本的には、お客様に「テスト駆動開発やってます」と胸を張って言うことではないんですよね。 どちらかというと「プロだから当然やってますよ」という話です。 自分達が書くコードに対して技を尽くしてますよ、という話なのだと思います。
お客様 (エンドユーザ、受託開発) に対して、「テスト駆動開発やってます」ということを売りにするということは、そんなにありません。
でも、言われることはあるんです。僕に仕事がくる場合「テスト駆動開発でやってください」と言われるのは多いんです。僕宛てに来た仕事なので、構図としてそうなっている側面はありますね。
大中 自分の感想ですと、シビアな仕様変更とかがあっても、デグレ無しでスパンといけちゃうとかは。
和田 テストコードがあってよかったなと。
大中 そうですね。TDD によって価値を提供できているなと。
和田 そうですね。
急激な仕様変更、急激なリリースであるとか、プレッシャーがかかる局面になると、人間は視野がぐっと狭くなって、自分の頭でチェックできる領域がすごく狭くなってしまいます。そのようなときに、それまでにやってきたことを機械が実行して助けてくれるというのが、テスト駆動開発を行って、テストコードを用意してきたことの大きい御利益が得られる瞬間ですよね。
また、開発期間が長くなったりすると隅々の仕様やテストコードについて覚えていなくても、何かを変えてどこかのテストコードが落ちれば、これまでと動きが変わったというのがはっきり Yes/No で分かるのも、自信、安心に繋がりますね。
杉野 「Microsoft が Visual Studio の開発 に TDD を適用したらバグが 9 割減った{{fn('[[http://www.tdd-net.jp/2009/12/tdd-boot-camp-3.html|http://www.tdd-net.jp/2009/12/tdd-boot-camp-3.html]]')}}」という話についてのは正直どう思いますか?
和田 あとで調べてみたんですけど、Visual Studio のアーキテクチャの大規模な立て直しのプロジェクトだったらしくて、割と本腰を入れてやってたらしいんですね。 バグ 9 割減ったというのは相対値の話なので、それまでみっちりテストをやっていて出ていたバグ数が、そもそも出なくなったって話なのかとか、そのへんをちゃんと考える必要はあります。
あとは、対象が複雑ということもあります。開発ツールなのでたくさん状態を持っているだろうし、たくさん振る舞いをもっているだろうし。
そういうものに対してボトムアップでひとつひとつの部品の完成度を高めて、それらの組み合わせ自体のエラーの混入率を一気に減らした、という効果なのではないかと思います。
おかざわ 9 割っていうのが、どこの数字を拾って 9 割なのかっていうのがあるかもしれないですね。
和田 そうそう。
大中 ある意味でいうと出てるんだけど、いわゆるテストフェーズ前のコーディング時点でもう潰しちゃっているかもしれない。
おかざわ 今言われた、単体レベルの数字も含めて 9 割だよっていうのと、結合レベルで 9 割減ってるっていうのは違いますよね。まぁ、そこは邪推なので。
おかざわ それで、2009 年のオブラブ{{fn('[[http://www.objectclub.jp/event/2009summer/session.html|http://www.objectclub.jp/event/2009summer/session.html]]')}}で発表されてた資料{{fn('[[http://www.slideshare.net/t_wada/emergent-design-oblove-2009-summer|http://www.slideshare.net/t_wada/emergent-design-oblove-2009-summer]]')}}を見せて頂いて疑問に思ったのですが、TDD で開発したシステムが死ぬというのは、アーキテクチャ的に死ぬということでしょうか?
和田 ボトムアップで設計したものがアーキテクチャ的にどん詰まりになるということを言っています。 例えば、小さい部品を組み合わせてテストコードもちゃんと動いてるんだけど、テストコードは基本的にシングルスレッドの世界として書いてしまうことが多いですよね。
マルチスレッドで動かないとか、いざ本番で実際のリクエストに晒してみるとパフォーマンスが悪い、といったことが出てきてしまうので、「ちゃんとアーキテクチャを事前に設計すべし」という意見が出てきたりするんです。
テスト駆動開発やアジャイル開発、オブジェクト指向設計の文脈でよく話題になったり、批判されることでもあるんですけど「高いレベルのメンバーじゃないとできません」という意見がありますよね。
ペアプロ時もそうなんですけど「暗黙の設計」は、あります。
どうしても、個々人の差とか、どのぐらい設計のゴールが見えて TDD やっているのかというところは、やはり経験の差だとか能力の差が出てくるところではあります。
その上で、ではなぜ TDD をやっているかというと、作っていくうちに最初思い描いていたゴールから微調整が必要だとか、やってみて初めてわかることが多いんですね。
最初からきちんと設計してその通りに実装すれば上手くいくかというと多分そうではないし、でも無から完全にボトムアップで組み上げていったら、たぶん全然違うところへたどり着いてしまう。その中間に良い設計というのがあるんじゃないんですかね。
大中 TDDBC 横浜のときにちょっと失敗したことなんですけど、課題を小出しにしたんですよ。
それはそれで、一つの問題に集中するという効果はあるんだけど、その上で、実際の仕事で何を作るかというところを、その場その場で小出しにして判断していくというデザインの仕方が本当に正しいのかどうかというと、ちょっとそれも違うなというのがあって。
和田 はい。
大中 何を作るのかというのが見えているんだったら、それはそれでオープンにしておいた上で、進んでいくところで見つかるズレをどうやって調整していくか、という対応がよいのかなと思ったんですよね。
和田 そう。横浜のときと C++ のときは課題を小出しにするスタイルで、それは目の前のことに集中できるという良い効果と、全体像が見えにくいという良くない効果と、その二つの効果があったと思っています。 別のイベントを開催をするときは別のやり方でやってみればよい、という有用なフィードバックだと思うんですよ。
僕がよく TDD の講演の中で言っているように、現実の問題は複雑でデカイじゃないですか。 それに対して一気に立ち向かおうとすると敵が大きすぎてやっぱり手が止まるんですよね。
だから、ある大きいゴールを達成するためには、小さいゴール。 これとこれとこれとこれができれば大きいゴールに到達できる、というように、はしごを掛けていかないといけない。
大きい問題を小さい問題に分解するというのは、ストーリーをタスクに分割するという話や、タスクをさらに小さいタスクに分割することや、 GTD {{fn('Getting Things Doneのこと。[[http://ja.wikipedia.org/wiki/Getting_Things_Done|http://ja.wikipedia.org/wiki/Getting_Things_Done]]')}}の世界にも通じる汎用的な話ですよね。
問題の分割には練習が必要です。 大きいゴールを提示するとそれを小さいゴールの連続に分解できない人はやはり多いです。 というか、訓練しないとなかなかできるようにならない。
おかざわ C++ のときは、最終的に経路探索をして路線の料金計算ができちゃうような主題に対して、そこから問題をだんだん分割しててそれぞれに課題をつけていくというやり方をされていました、途中で井芹さん{{fn('[[http://d.hatena.ne.jp/goyoki|http://d.hatena.ne.jp/goyoki/]]')}}が講演資料を作ったら、各課題とテストの設計が課題として設定されるようになって、結局 10 段階ぐらいになったんですっけ?
和田 10 問ぐらいになってますね。
おかざわ タスクとしては分割されていて、かつテストの観点も同時に含まれていたのですが、最後のゴールが見えず途中でアルゴリズム大会になってしまった。
和田 そうですね。現実問題としては、全体を見ながらという、複眼視が必要ですね。 全体を逃さないようにしながら、でも目前のものに集中してやっていった方が効率がよい。 だから、遠くのゴールを片目で見ながら、そこにたどり着くために近くのものを小さく設定して倒していく。
大中 それにどうやって立ち向かっていけばいいのかって考えるときにたどり着くのって、やっぱり Kent Beck の『テスト駆動開発入門』のタスクリストを出して、ひとつひとつ立ち向かっていくっていうやり方に近づいていく。
和田 近づいていきますよね。 大きな講演の度に、『テスト駆動開発入門』や『リファクタリング』を読み直すんですけど、いっぱい走っても結局 Kent Beck の手のひらから出ていない、 Ward Cunningham の手のひらの上を出ていない、という感覚になります。 なんかこう、お風呂の中で TDD 本を読み直していて、「ああ、結局ここに書いてあるじゃん」ってなりますね。
TDD 本と『リファクタリング』の最後の一章(第 15 章)は Kent Beck が書いているんだけど、そこにだいたいすべてのことが書いてあるので、「ああ、また俺は手のひらの上か」みたいな感じがすごく出てしまいます。
おかざわ xUTP 本{{fn('書籍 "xUnit Test Patterns" の略称。[[http://www.amazon.co.jp/dp/0131495054/|http://www.amazon.co.jp/dp/0131495054/]]')}}の中にパターンとして記載のあった INSIDE OUT と OUTSIDE IN についてさんざん議論したじゃないですか。{{fn('xUTP本の読書会でとりあげていた重要ポイントに触れずに、xUTP本の前の世代の本になる『テスト駆動開発入門』まで遡っていることを指摘している。')}}
大中 それ、俺に言ってる?(苦笑)うん、でも確かに、 OUTSIDE IN と INSIDE OUT の考え方は重要。あれでテストに対する考え方が変わった。
和田 ほう。
大中 僕の場合、あれ読んでからしばらくは INSIDE OUT に寄り過ぎていて、テストは書いたんだけど、コンポーネントとして組み合わせると動きませんとかそういうのがあって。ようやっと、この前のプロジェクトで方向転換できたかなというとこなんですけど。
和田 画面に近い、要するにユーザに近いところから作り始めるやりかたですね。例えば受け入れテストとか、いわゆる MVC でいうとコントローラやビューから作って、内側をモックにして、要求の方から作っていって中に攻めていく方針が OUTSIDE IN というテスト戦略。 そうじゃなくて、抽象的な部品とかモデルレイヤから作っていってボトムアップで攻めていくのが、INSIDE OUT 戦略。
Kent Beck や Fowler がやってた 2000 年ぐらいの TDD の姿と、その後の Steve Freeman とか Nat Pryce とか goos の人たちがやりだした TDD との大きな違いというのは、「向き」が出てきたということですね。
Kent Beck がやっていたのは、抽象的な話で、「テストの向き」という概念は基本的に無かった。 それに対して、モックオブジェクトを作った Steve Freeman と Nat Pryce は、モックオブジェクトを使うことで、テスト駆動開発自体は、開発する要求や対象の世界を自分たちが理解していく上での設計ツールになり得るし、設計の時間を制御できることに気づいたんですね。 最初から全部を理解するのではなくて、その人たちのソフトウェアに対する理解をだんだんと、見えている外側の界面から中側に向かって攻めていくことができる。
それまでは、実装がないとテストができない、実装がないとインテグレーションもできない、という状況でした。 それが、オブジェクト指向言語とモックオブジェクト (テスト用の偽物) という道具を組み合わせてテストに使うことで、決まっているところはともかく、決まっていないところでも実装のことを考えずに外側から決めていくことができるようになったことに、テスト駆動開発をやっている一部の人たちが気がついたんです。 それが OUTSIDE IN 戦略。
システムに対してテストする方向もそうだし、時間でもあるんですね。 外側から先に作っていくという話なんです。学びと時期をテストで制御する。
和田 モックオブジェクトには良いところも悪いところもあります。モックオブジェクト自体はメンテナンス対象になるから、例えばモックオブジェクト自身がリファクタリングを妨げてしまうような状況を避けるための設計をしなければならない。
デザインパターンが出たときに、みんなデザインパターンを学んでデザインパターンを可能な限り使おうとしたじゃないですか。 シングルトンパターンを憶えたらみんなシングルトンオブジェクトにしちゃったりとか。なりましたよね?
大中 なりますね。(苦笑)
和田 だから、あれは麻疹なんですよ。デザインパターンもそうだし、モックも。 大事なのは、モックをすごいと思ったら、一度モックをばあーっと使ってみるということ。 そうするとモックのメンテナンスコストとか、モックは結局自分の妄想に過ぎないという現実に直面して、元の世界に戻ってくる。
RTP、"Refactoring to Patterns"(邦訳『パターン指向リファクタリング入門~ソフトウエア設計を改善する27の作法』)の中に patterns happy という、「パターン大好き」みたいな言葉が出てきて、かくたにさん{{fn('角谷信太郎さん [[http://kakutani.com|http://kakutani.com]]')}}と「これどうやって訳す?」って話してて、「これやっぱり"厨"じゃないか?」って話をしていたんですけど。「パターン厨」。
一同 わははは。
和田 モック厨。中二病っぽい。強い技術というのは人をぐっと引きつけるし、オーバーユースするときがある。
それで、これは使いすぎたなぁといって元の場所に戻ってくる。 その真ん中ぐらいにちょうどいいバランスがある。 だから、早めに羅漢しましょうという話なんですよ。
厨を呼ぶ技術は良い技術であることが多いし、早めに触れて、早めにちょうど良いバランスを見つけましょう。
『パターン指向リファクタリング入門』はすごくいい本ですよ。著者の Joshua Kerievsky はよくわかっている人です。(手元の iPad を見つめて)ああ、「パターン魔」って訳されてますね。なるほど。
大中 ここでいう「ハッピー」って、どっちかっていうと「ハイテンションになる」っていう意味でしょうか。
おかざわ 『アドレナリンジャンキー』的な{{fn('[[http://www.amazon.co.jp/dp/4822284018/|http://www.amazon.co.jp/dp/4822284018/]]')}}。
和田 そうそうそうそう。
杉野 さっきちょっと言われてましたけど、お風呂の中でも本読まれるんですね。
和田 読んだりしますよ。iPad で読むことも多いんですけど、疲れてくると画面から離れてみたくなります。紙と鉛筆で考えたい。いいアイデアって散歩中とかお風呂に入っているときとかに浮かびがちですよね。
おかざわ TDDBC にこれから参加しようと思っている人と、もう参加した人に伝えたいこと、目標としてもらいたいことをお願いします。
和田 参加したい人は、怖くないので気軽に来てくださいと言いたいです。まぁ、未だに倍率が高いのが悩ましいんですけど…。
でも、体験からしか学べないというわけではないです。
僕は TDD は基本的に自習できる{{fn('和田さんによる技術書の写経の仕方 [[https://twitter.com/#!/t_wada/statuses/9000231741|https://twitter.com/#!/t_wada/status/9000231741]]')}}と思っています。ですけど、コードレビューやペアプロは他者がいないと成立しないので、そういう空間、非日常の異空間を用意するというのが、TDDBC のひとつの舞台装置としての効果であると思っています。そういう体験はとても強烈なので、ぜひ体験して欲しい。
参加したいと思って確実に参加できる手段は「自分で主催する」ことなので、小規模でもいいので、何かいろいろやってみるというのがいいんじゃないでしょうか。ぜひ気軽に相談してください。
TDDBC に参加した人に対して伝えたいのは「自分で咀嚼して自分の言葉にして伝える」ということ。 実際、人に伝えようとして初めてわかることがすごく多いんです。 コンサルティングの現場でも、お客さんの話を聞いてから自分で言い直して返す、というのが基本テクニックじゃないですか。
人に対して説明してみようと思うときに、初めて自分の中で再構築されて理解が進むのだと思います。 自分の会社に戻って、TDDBC で体験したことを隣の人に伝えてみるとか、部署内で勉強会をやってみるとか、そういう機会をつくって自分が教える立場になると、自分が一番学ぶことができます。
自分が何を学んだのか、ということを、今度は人に伝える側になっていただけたら嬉しいなと思っています。
まとめると、これから参加する人は怖がらないで来てみてね、というのと、参加した人は学んだことを日々の行動に還元するとどうなるかを考え、人に伝えてほしいということですね。
あと最後に、テスト駆動開発は自分ひとりで続けていけるものであり、こつこつと練習することが上達につながります、と重ねて言いたいです。
おかざわ 好きな女性のタイプは?
和田 奥さんです。
杉野 どんなところが?
和田 好奇心が強いところですかね。奥さんが自分がやってることに興味を持ってくれるところです。
おかざわ xUTP読書会{{fn('xUnit Test Patterns(xUTP)読書会 [[http://www.fieldnotes.jp/xutp/|http://www.fieldnotes.jp/xutp/]]')}}ってなんで 2 年間も続いたんですかね?
和田 本が分厚いからじゃないですかね。
おかざわ 他にも分厚い本を前に自然消滅した読書会を知っているので、そこが不思議に思っています。。
大中 xUTP 読書会って何で最後まで終わったかというと、一番大きな原因っておかざわさんが加わったからでしょ?
和田 そう。そうだと思う。 xUTP 読書会がなぜ完遂できたかというと、おかざわさんが途中で「おかざわブースター」として入ったというのが大きい。 やっぱり一定出力でアウトプットをし続けられる人が会の存続に必要ですよね。
おかざわ へえー。
大中 僕、けっこうムラっけあるんで。
和田 ムラっけ、あるある。 後は、継続するのに月イチぐらいがよいテンポなのかもしれないですね。xUTP 読書会の母体となった『RESTful Webサービス』{{fn('[[http://www.amazon.co.jp/dp/4873113539/|http://www.amazon.co.jp/dp/4873113539/]]')}}の読書会{{fn('RESTful勉強会 - RESTful読書会 [[http://kunit.jp/restful/wiki/|http://kunit.jp/restful/wiki/]]')}}からですかね?
大中 母体では無いけど、そうか、きっかけはそうなんですね。
和田 きっかけにはなったけど、メンバーは母体にはなってないか。
大中 『RESTful Webサービス』の読書会に僕が参加して、帰り道に和田さんに「レガシーコード本の読書会をやろうと思うんですよ」って言ったのがきっかけなんですけど。
和田 おおー、そうだった。
おかざわ たしか和田さんのブログでコメント欄が燃え上がった{{fn('[[http://d.hatena.ne.jp/t-wada/comment?date=20080224#c|http://d.hatena.ne.jp/t-wada/comment?date=20080224#c]]')}}のが。
和田 あー、ブログもきっかけかもしれないですね。「読書会フラグですね」みたいな。
大中 コメントが 40 個以上ついたのが。あれひどかったよなぁ。
和田 レガシーコード本のときはサイボウズ・ラボの中谷さんに会場をお世話になったし、勉強会/読書会には定期的に場所を提供してくださる方と定期的にアウトプットしてくれる方、その二人が大事ですね。
大中 その二人が揃えば、まぁ、勝利ですね。
和田 レガシーコード本のときも xUTP のときもそうだったけど、毎回場所を探すのは結構きついですよね。 毎月開催できる場所を手に入れるのが、定期的に開催する読書会に必要なパターンですよね。
で、僕が参加し続けてたのはなぜかというと、まぁ、基本的に好きなことだったからだと思いますよ。
おかざわ 一通り読んだ上でやっぱり参加されてるじゃないですか。
和田 ざっくりとは読んでいるんですけどね。読書会はもっと深く読み込むからやっぱり理解も違ってくる。 goos本の読書会もみんな訳してきてくれたりするので、怖がらずに来てくださいねというのは言いたいです。怖くないです。
おかざわ 最後にひとつだけ。初回のぺけま、とりあえず xUTP の裏表紙にあるパターンを全部概略付きで、手抜きなんですけど(笑)、載せてたりとかするんですけど、 5 点満点で何点?
和田 えー。
おかざわ 「俺はこんなもん求めてねえよ、俺が求めてたのはこのぐらいだよ」とか。
和田 5点満点でいうと…。じゃあ、 4 点。
大中 おおー。
和田 5点満点というと、これがマックスなのかみたいな話になっちゃうから。
巻頭言もかなり熱い感じになってたし、xUTP 本を概覧するという最初のまとめ記事もすごい力が入ってましたよね。
有志のクオリティでこれを続けるのは難しいところなので、どうやって人を巻き込んでいくかとか、読者を増やすかといったことが、定期的に、不定期でもいいと思うんだけど、これだけのアウトプットを続けるために重要になりますね。
やはり Web 媒体って、紙媒体と違って編集しやすいし、修正しやすいし、フィードバックが得やすいし、技術的な情報を発信するのに向いている媒体だと思います。さっき言われていたように、Java の情報が足りないのであれば、 Java の情報をぺけまでやっていけばいいだろうし、ニーズのあるものを書いていく、そういう媒体として育てばすごいなぁと思います。
実際今日(収録日)もたくさん反応がありました。今日僕がはてぶを Twitter に投げたら多くの方に RT されたんです。{{fn('[[https://twitter.com/#!/t_wada/status/137084843103223809|https://twitter.com/#!/t_wada/status/137084843103223809]]')}}
杉野 されてましたね。
和田 僕がはてぶ投げ忘れてて、今日がちょうどいいタイミングだと思って投げたらバーンと 22 RT。
和田 ぺけま第一回出たのって 4 日ぐらいですよね。
大中 だって、あれ TDDBC 横浜当日( 2011 年 11 月 5 日)ですよ。和田さんが基調講演している最中に公開したという(笑)。
和田 あれでタイミングを失っちゃったんですよ(笑)。はてぶで 1 ゲットしようかとしていたら、俺が喋ってるところで公開。
一同 爆笑。
大中 あれ、僕が朝イチで公開しようと思ってたら、編集がまだ終わっていなくて(笑)。
和田 そういうことだったのかぁ。
おかざわ 間違いを指摘してくれる人がいて、ちゃんと読んでくれてる人がいて嬉しかったです。
和田 フィードバック募集をどうするかですね。
大中 メールアドレス作るのはできるんだけど、さて、どこに流せばいいんだろう。
和田 #xutpハッシュタグをつかってもらうとか、 公式ハッシュタグってどうしますか?
大中 あと、イイネボタンとかも押せるようにしたいんだけど、あれどうやればいいんだろう。
和田 これで次の人にバトンタッチするとかあったりするんですか?
大中 なんも決めてないです。
杉野 指名するんですか?
和田 どうなんだろ?誰のインタビューをやりたいとかあったりします?
大中 僕がぼんやり思っているのはこんぴろさんなんですけど。
和田 ああー、それは面白いな。
大中 オンラインのインタビューになりますけどね。福井なので。
和田 そうか、最近物理的に見ないと思ったら福井にいるのか。
大中 福井で TDDBC を開催して福井に行くって手はありますけどね。発行がイベント駆動なので。
和田 締め切り駆動は大事ですよね。アジャイルにやるというかデリバリは決まっているからスコープを落としていくっていう。
一同 笑。
和田 今回は二本しかありませんっていう。それは面白いかもしれないですね。 僕がこれまで書いた文章とか色々ぺけまに寄稿していければなって思います。
おかざわ 誰がインタビュアーをやるかっていうのもあるんですけどね。
和田 僕がインタビュアーの側にまわっても面白いかもしれませんね。
おかざわ 和田さんがインタビューしたい人ってのもいいかもしれませんね。
大中 僕が Twitter に「和田さんにインタビューしたい人いませんか?」と書いたら、おかざわさんが「それ群がってきたらどうすんですか」って言ってたけど、僕はまぁ、なんとかなるさと思っていたら、ちょうど杉野さんが。
杉野 僕が釣れたっていう。
大中 ちょうどいい感じになった。
和田 katzchang さんとか bleis さんとか、最初に TDD Boot Camp のきっかけを作ってくださった人達とか、goyoki さんたちの話が聞きたいなと思いますね。
おかざわ そのあたりは調整させていただいて。
和田 はい。
おかざわ というわけで、ありがとうございました。
一同 ありがとうございました。
]]>ぺけま第3号をお届けします。
今回は、編集作業の関係で前後編になった和田さんインタビューの後編、ぺけま初登場@tomy_kairaさんのgoos_jp読書会への誘い、来年の(2012年)のTDDBC予報の三本立てです。
「ぺけま」の第1号をリリースしたのが2011年11月5日ですが、そこから2011/11/30に第2号、そして本日2011/12/31に第3号リリースとハイペースな出版スケジュールとなりました。来年の出版スケジュールはまだ検討中ですが、良質なコンテンツを提供できるよう編集スタッフ一同尽力していきますので、来年もよろしくお願いします。
]]>札幌でのTDDBCは6回目の開催ということで、テスト駆動開発の未経験者の参加率も低くなってきました。そこで、今回のTDDBCではあえて基調講演を行いませんでした。より課題を行う演習の時間を多くとりたい事・基調講演は何度も聞いている人が増えている事・和田さんのTDD入門ビデオやTDDBCのUst録画が公開されていること・運営の負荷を減らすことなどが理由です。現状、TDDBCというイベントは和田さんの基調講演で支えられている側面が大きいのは事実です。しかし、何時までもそれでは和田さんの負荷が掛かりすぎてしまいます。そこで、参加者のスキルアップを基調講演のないTDDBCで行い、新しく興味を持った人のために基調講演のあるTDDBCを行うべきかと思います。{{br}} 尚、今回の参加者はスタッフ込で10名。3名ほど今回のTDDBCへの初参加でした。
とはいえ、講演が一切無しというのも寂しいです。そこで、今回は「テストリストの見つけ方」という題目で20分ほどセッションを行っています。内容はTDDBC横浜で発表した内容とだいたい同じですので、資料はこちらからご覧ください。
セッション終了後は、セッションの内容やテスト駆動開発そのものに関する疑問などをディスカッションしました。時間にして30分以上盛り上がっています。内容としても、実際にTDDをやりはじめた中での疑問や、どのようにして開発チームに浸透させるかといった現実的な問題に参加者がぶつかっていると感じるないようです。そんなリアルな話が出来るようになってきたのは非常に喜ばしい事です。
言語は6名がJavaへ、4名がSmalltalk(とHaskell)となりました。それぞれでチームを分け、最終的には4チームで課題を進めました。このあたりは人数も少ないのでフレキシブルに行えています。また、TDDがまったくの初めてという人の割合が低いため運営の負荷もありません。{{br}} 今回は、テーマを「基本に戻る」とし、TDDBC札幌1.0でも使用したLRUキャッシュ(使用頻度や時間で古いデータが消えていくkey-valueコンテナ)を課題として使用しました。ただし、参加者のTDDへ練度も異なるため、慣れないチームではFizzBuzz問題など、簡単な課題からチャレンジしてもらっています。
札幌開催の特徴としては、だいたい夜の8時くらいまでを演習にとっている事もあげられます。特に今回は11時には演習をはじめてので、8時間ほどを演習に当てられました。この時間を演習に当てられると、レビューも3−4回可能ですし、チーム数が少ないため、毎回全チームのレビューも可能です。レビュー時間は休憩にもなりますし、アイディアをもらえたり刺激をもらったりできるため、TDDBCの醍醐味の1つでしょう。
結構長い時間を確保していても、TDDBCはあっという間に過ぎていきます。それはプログラミングが楽しいからに他なりません。ですが、しっかりと振り返り、糧としなければ「楽しかった」で終わってしまいます。{{br}} 振り返りで一番多かった感想としては、TDDにも少しずつ慣れてきて色々考える余裕が出来てきた・繰り返しやることが大切という点です。これらは、まさに継続開催している理由ですので主催者として喜ばしい所です。逆に、Java、Ruby、Smalltalkあたりしか実質的に選択肢がないのがTDDBC札幌の課題かと思います。PHPや.NETなどTDDをやりたい人はいるのですが、人数が集まらなかったりリードする人が居ないのが現状です。少人数でやる中での限界なのですが、是非自分の言語でもやってみたい人がいたら名乗り出てください
札幌では2011年11月現在、通算6回のTDDBCを開催しています。さらに、12/3にもTDDBC札幌2.3開催を予定しており、昨年の12月から概ね2ヶ月に1回というペースで開催してきました。基調講演として和田さんが参加されている回は2回ですが、それ以外の会については地元の有志による主催でテスト駆動開発を学んでいます。{{br}} 参加者の中にも日常的に業務で取り組み始めた人、開発チームに少しずつ浸透させようと活動している人、テスト駆動開発に慣れ始めて新しく参加してくる人に伝える側に回る人と、少しずつですがレベルアップをしてきていると感じております。絶対数で言えば首都圏の何十分の1という数かと思いますが、札幌の開発者のテストへの意識に関しては高い方向へ進んでいると思います。{{br}} そもそも日本のソフトウェア開発は首都圏にほぼ全ての人材と情報が集まっていると断言しても過言ではありません。地方へと目を向けるとそこには20年前から変わらない開発が行われている事もしばしばあります。地方ではより新しいものに対する変革への抵抗は強く、新しい技術に関する伝搬は遅れます。{{br}} TDDBC札幌は2009年の秋頃、Twitterで和田さんにTDDBCを札幌でもやりたいんだけど...というDMを送り即時に快諾された事が発端です。その後、継続的にやる事でもっとたくさんの人に、そして自分のスキルアップのために開催したいと続けてきました。みなさんの地域でも地方だから...と考えずに開催してみてください。少人数で実施するならば運営の負担もそれほど高くないですし、近隣地域からスタッフ経験者を招待すればどこでもBootCampできるはずです。
]]>こんばんは。goyokiです。
先日TDD Boot Camp for C++にてTDD入門の次のステップについて講演させていただきましたが、今回はその補足・復習として、ユニットテストの構築と保守について解説させて頂くことになりました。雑多な連載となるかもしれませんが、一連の記事がTDD習得の一助となれば幸いです。
RED→GREEN→REFACTORの基本サイクルを回していくうちにありふれた作業となるものに「テストコードの再利用」があります。 例えば過去に書いたテストコードを使ってリファクタリングを実施する、過去に書いたテストコードを変更してREDにする、といった感じにです。
その「テストコードの再利用」は、製品コードの保守と同じく色々な手間や問題が存在します。ただ一方で、TDDの作業を様々な面で支えており、結果的にTDDの恩恵の一部を構成しています。今回は連載の前提知識として、そのユニットテストのサポート効果について解説したいと思います。
まずユニットテストは製品コードの理解を助けることで、TDDの各種作業をサポートします。
例えばテストコードの構造や名前の工夫により、実装仕様を示すドキュメントとしてユニットテストを扱えるようになります。このテストのドキュメントとしての用途はxUnit Test Patterns等でしばしば「Tests as Documentation」と呼称され、テストで達成すべき目標の1つとされています。
またコードの入出力をテストの追加でどんどん明示化していくことで、コードの理解を深めることができます。この手法は仕様化テスト(Characterization Test)と呼ばれるテクニックです。中でもコードのふるまいを学ぶことを目的とした仕様化テストは学習テスト(Learning Test)と呼称されています。やはりこちらもテストを一種のドキュメントとして扱います。
こうしたユニットテストのドキュメントとしての有用性は、リファクタリング・Assertファースト両方の作業をサポートします。
例えばテストコード上で製品コードの用例・使われ方を表現してみることで、製品コードのインターフェースの良否を評価することができ、リファクタリングの必要性を決定することができます。
また、以下のような問題の絞り込み手段を実現することから、Assert Firstや意図しないデグレード対応のサポートとしても活用できます。
この工夫の具体例にデバッギングテストが挙げられます。デバッギングテストはバグの再現手段・バグ発生個所の切り分け手段として、ユニットテストを活用する手法です。具体的には以下のような手順を取ります。
なおこのテストコードで実現するドキュメントは、(テストファースト手法を除けば)従来のjavadocやdoxygenなどで実現されるような、コードの解説資料のようなものに位置付けられます。ただテストコードの場合、従来の資料と違ってテスト結果でドキュメントとコードの矛盾を把握可能なため、追加・変更が柔軟にできるのが強みです。
さらにユニットテストはコードの再利用性を補強する点で、リファクタリングおよびAssertファーストによる追加変更を支えていきます。
例えば定番ですが、リファクタリングでは、事前にユニットテストで既存コードのふるまいを保護することで、コードの設計改善をデグレードなく行えるようにしていきます。
また追加・変更でも、以下のような手順を取ることで、デグレードを防ぎ、かつ変更・追加が意図したとおりに達成されたことを確認できるようになります。
なおこの「テストで保護してからコードに手をつけるアプローチは、Cover & Modify(保護して変更する)と呼ばれます。Cover & Modifyのメリットは小さくなく、それを実施できるかどうかは、変更・再利用を安全かつ簡単にできるかどうかに大きく影響します。すなわちCover & ModifyのやりやすさはTDDのやりやすさに直結するといっても過言ではありません。
そしてユニットテストは自動化された回帰テストとして継続実行することによって、テストが損なわれる変更の早期検出や、コードカバレッジといったテストの継続評価が実現されます。 そうした継続的な保守サポートは、テストをいつでも利用可能な状態に維持することを助け、前述した「仕様化テストでコードの理解を進める」「Cover & Modifyで変更の安全性を高める」といったメリットをいつでも活かせられるようにします。
上記のような効果を持つため、ユニットテストの再利用・継続的活用はTDDにおいて推進すべきものと考えています。ただユニットテストの再利用を続けるためには、様々な課題に直面することになります。
例えばその1つとして、テストの網羅性の作りこみがあります。例えばTDDでも網羅性の劣ったテストを書くと、REFACTORでバグを埋め込んだり、Assertファーストで適切にコードを追加できなくなってしまったりするリスクが高まります。しかしかといって、時間のかかるテスト設計手法の採用や過剰なテストの網羅性作りこみを行うと、保守コストやTDDの効率を悪化させる恐れがあります。
次回以降では、そうした課題がどういうものか、またそれにどう立ち向かっていくかについて解説していきたいと思います。
]]>