忍者ブログ
プログラミングとか日常とかの覚書っぽいなにか
[40] [39] [38] [37] [36] [35] [34] [33]
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。

昨日は「TDDBC横浜 Second Season」があったので参加してきました。
今回TDDBCは初参加(勉強会自体2回目だけど)。もともと今回の参加枠が30人で、申し込みはどうやら倍くらいあったようなので、抽選に当たって運が良かった。   

9時半受付で、ほぼその時間に現地に到着。場所は横浜駅西口から数分の位置にある株式会社アットウェア。
受付で参加費(懇親会と合わせて3500円)を払って、ネームプレートを書いて、とりあえず右後ろのテーブルの、扇風機の目の前の席へ。なんせ暑かったですから…。


基調講演

10時から開始。まずは、川西さん(@tosikawa さん)による基調講演。
『テスト駆動開発入門の入門』というタイトルでしたが、このタイトルは「テスト駆動開発の「入門の入門」」という意味ではなく「「テスト駆動開発入門」の入門」なんだそうです。つまりTDDのバイブルともいえる書籍『テスト駆動開発入門』(ケント・ベック著)の入門。

川西さん曰く、TDDやってる人とは、『テスト駆動開発入門』の写経をした人のことだそうです。たとえTDDのやり方で開発していようが、『テスト駆動開発入門』を読んでいようが、『テスト駆動開発入門』の写経を写経をしたことがないなら、その人はTDDやってるとは言えない!とかなんとか。私も読んではいるけど写経したことないんで、一からやり始めないと。

講演の内容としては

  1. 『テスト駆動開発入門』の「まえがき」について
  2. 『テスト駆動開発入門』の「はじめに」について
  3. 『テスト駆動開発入門』の「Part I」について
  4. 『テスト駆動開発入門』の「Part II(ry
  5. (ry

私が前にこの本を読んだときに「まえがき」とかちゃんと読んだかどうか怪しいものですが、読者をこの本に(すなわちTDDに)引き込むための部分だけあって、実は大事なことがまとまって書いてありました。
出だしの「動作する綺麗なコード」がTDDの目標であり、この一文がすべてを物語っています。

その「動作する綺麗なコード」を書いていくための具体的な説明や方法が Part I やら Part II やらにまとまっていたわけです。今回の基調講演を聞いて、もう一度『テスト駆動開発入門』を読み直そうと思った次第でした。もちろん今度は写経も含めて。

これまでTDDBCは、和田さん(@t_wada さん)が基調講演を行うことが多かったようですが(私もWeb上にアップされてるTDDBC基調講演の動画や資料を見たことがあります)、今回のように他の方々が講演をできるようになってきてくれてうれしいと、和田さんもおっしゃっていました。


ペアプロ・TDDデモ

基調講演の後は、「ペアプロ・TDDデモ」。
実際にペアプログラミング&TDDで今回の課題のステップ0の部分を進めていく様子のデモンストレーションを見ることができました。

TDDで重要なのは、道筋を考えずにいきなりテストコードを書き始めようとすると、1歩先は見えているけども、さらにその先が見えておらず、結果的に間違った変な方向へ進んで行ってしまうという可能性がある(1人でTDDやると場合は特に)。従って、あらかじめTODO的なことをテストリストとして書きだしておいた方がよいのだそうです。

テストリストを作成していく際には、まず最初に課題を上から順番に見ていくのではなく、課題のなかからもっとも単純な動作を探します。例えば、今回の自販機の課題(ステップ0)の場合は「投入金額の総計を取得できる」の部分。特に、「何もお金を入れていないときの総計が0円」というように。

また、小さなステップで進む場合、テストケースが通るようなべたな実装(「仮実装」、単に0を返すだけのような)を先に書くようにすることで、テストコードに間違いがないかを知ることができるのだそうです。仮実装でテスト結果がレッドになってしまった場合、テストコードの方が間違っているのです。もし実装を書いた後にテストコードが正しいことを示そうとすると、多大なコストがかかってしまうようです。

その他の着目点、注意点としては
  • テストメソッドの名前は日本語でよい。(言語仕様やコーディング規約が許すなら)
  • テストコードを下の行(ゴールとなるアサーション)から書く。(慣れてない人は特に。慣れてきたら普通に書いてよい)
  • 開発ツールのショートカットを活用する(コードテンプレートの自動挿入など)
  • テストメソッド名は適切になるように決める。
  • 適切なタイミングでリファクタリングを
    • テストコードのリファクタリング:
      3回くらい(デモでは2回だった)テストコードの重複が発生したら、例えばSetUp(準備メソッド)にまとめる
    • テスト対象のリファクタリング:
      コードやクラスが保持する情報の重複が出てきたら、テストが通る状態を保持したまま(外から見た振る舞いを変えないまま)コードをきれいにしていく

昼食

ペアプロのデモの後はお昼ご飯。

お弁当が準備されていました。あまり好きじゃない梅干しが……この時期は暑さで傷みやすいので、それをある程度防止するために梅干しを入れるってのは常識ですかね。食べれないほど嫌いというわけでもないので、いただいておきました。すっぱい!


TDD&ペアプロ実践

午後は実際に他の参加者とペアを組んでTDD&ペアプロ実践でした。
1時間半くらいのTDD&ペアプロ実習の後、どれかのペアのコードレビューを30分(15分×2ペア)というセットを、休憩をはさみつつ3セット。3回目の直前で、ペアの交代なども行いつつ。
今回C++で参加してたのが私と大鷲さん(@aetos382 さん)だけだったのでペアの交代はありませんでした。

課題の内容は以前のTDDBCから同じものが使われているらしく、英語に困らないように仙台02の時点で用語集まで作られてるらしいです。

C++選択しておきながら、C++用の環境構築のページに乗っていたPCUnitはダウンロードしておいたもののビルドとか試していない状態でした…。あと、いつの間に追加されたのか、GoogleTestの環境構築の説明が知らないうちに追加されていました…(前日に追加されたらしい?)
なので、ペアプロは大鷲さんのPCを使ってやることに。彼のPCはWindows 8 (RTM) とVisual Studio 2012を入れてるらしい。これはこれでいい!と思いました。Visual Studioもスムーズに動いてるし。

リビジョン管理はMercurialを使うことに。その場でTortoiseHgをインストール。
ひとまずローカルでリポジトリを作って開発を進め、あとで共有できるようにしてもらうことにしました。

私達のペアは、紙にテストリストを書きだしていって、それをもとにテストケースを作っていくという形を取っていました。ただ、なにぶんTDD初心者同士ということもあって、デモで見たものと比べてもちゃんとしたものが書けていなかったように感じてしまいますが…。デモでは型をどうするかとか言うことも含めて書いて言ってたと思うんですが、私達は口頭で確認した程度になってしまった…。

途中他のチームのコードレビューも見てると、言語ごとにテストコードの書き方に特徴があっておもしろいと思いました。そして、うちのチームの進み方はちょっと遅いのでは……などということも。
自分たちの発表時にTAの方の話によると、同じことをしようとすると、C++は他の言語と比べて開発のスピードは遅くなりがちなんだそうです。「でも実行速度は他のどれにも負けません」などという話も。まあ、この辺はコードの作り方にも左右されるので一概には言えないんでしょうけどね。

コードレビューは言語ごとに1ペアが発表だったので、C++の唯一のペアである私たちは必然的にコードレビューをされるペアとなりました。5ペア目(3回目のコードレビューの最初のペア)の発表だったので、最初の2回のレビューのなかで私達に足りていない部分など気づくことができました。

そんななか、「無効なお金(1円玉とか5円玉とか)をお釣りとして出す際に、投入後すぐ出すのか、購入後のお釣りと一緒に出すのか」という議論があり「ならば『お釣り受け』を作って、投入時に無効なお金がそこに入るようにしよう」という方針にまとまりました。他の発表済みペアのなかではそのような考え方を取っているところはなかったようなので「これはいい考えだ!」という感じで。
ただ、その方針が決まったのはすでに3回目のペアプロ実践の時間になってからで時間がなかったので、とにかく最初にその方針をテストリストにまとめてしまおう!ということで、テストリストをつらつらと記述。
そして、それを1つ1つテストコード作成&実装、と進めていきました。

実習中に書いてきたテストリストやメモ書きはこんなの。


コードレビュー時の発表については大鷲さんにおまかせしちゃいました。
最後に決めた方針がよかったおかげで、進み具合は他のペアと比べて遅かったにもかかわらず、受けはとてもよかったようです。

今回の私達のペアの成果を大鷲さんがbitbucketにリポジトリをアップしておいてくれました。
https://bitbucket.org/aetos/tddbc_yokohama2/src/9af7a916e3e9/TDDBC_Yokohama2_GoogleTest

……ええ、 Commit 146743418a69 見ると分かるように、肝心のファイル(VendingMachineクラスを定義してるファイル)を最初にaddするのをすっかり忘れてて、変更履歴が残ってなかった……これは痛い、ホントに残念。最初に環境丸ごと(すでに存在した .obj や .exe も含めて)リポジトリにつっこんでしまっていたので、VendingMachineクラス以外のソースを変更していなかった場合でも変更ありとして認識されてしまい、気づくことができなかったようです。コミット時にもっとちゃんと確認していれば…。

教訓: git や hg では status の確認も大事


質問コーナー

TDD&ペアプロが終わった後は質問コーナー。
分からない内容も多く、聞き逃してしまったものも多いです……。多分誰かがブログとかでまとめてくれるに違いない。

Q.コードが変わったらテストを直さないといけなかった。しょうがない?
  • しょうがない。
  • テストコードを先に直すこと
  • 内部構造を変えただけでテストが落ちるようになるんは、テストが実装寄りになってる可能性がある。
  • 最近はテストの粒度を複数準備する(内部を調べるユニットテストと、外からの振る舞いを調べるもの)ことも多く、その場合は内部的なテストは壊れるが、外から見たほうのテストはGreen to Greenになっているべきである。

Q.JUnitでRSpecのように機能で分類する方法はある?
  • Enclosedでできる
  • テストコードをGroovyにするという手も
(正直、他の言語のことは言ってる意味がさっぱりわかりませんでした…。)

Q.シナリオ的なものはどこまで考えるべき?
  • 機能的なストーリーを作ってから。ここまでできたら作れるだろうなという目途が付いたら、そこから先は作るときに。
  • 自販機は一種の状態機械なので、すべての状態を考えるのは無駄が多い。テストとしての意味合いを失わない範囲でテストを選ぶのがテスト技法。

Q.TDDでテストを書く順序について。課題のステップ0でお金を入れる/入れない、合計/釣り銭の組み合わせで何通りもできるが。
  • 先にテストケースを挙げておいてテストコードは空(ignore)にしておき、後から実装しやすい順位テスト追加&実装をしていくという手もあり(本来はテストリストがその役目を負うが、そのように書くことも良くある)

Q.TDDをEclipseでやるときのおすすめテンプレートなど
  • 「ググれ」
  • Ctrl+O でアウトラインとか
  • テンプレートは自分で作れるので、ググるといろいろ出てくる

Q.Git Commitのタイミングはいつ?
  • 「gitを手でコミットする時代は終わりました(キリッ」(オートコミット)
  • ただし、オートコミットの場合は保存したタイミングで(テスト結果がレッドでも)コミットされる。それはそれで問題ないという考え方もある。
  • git now ……でもコミット忘れをすることはある
  • ちまちまコミットすることが重要

Q.納期に間に合わない!テスト書かないとダメ!?
  • 「テストしないと納品した後どうなりますか?」
  • 全部テストを書くことは難しいのでテストを書きやすいものを、後からでも書いていくのが王道
  • テストを書いていくことでポカミスが少なくなっていく。慣れてくると開発サイクルが短くなっていく
  • 「書いていきましょう」だけではテストを書くようにならない。テストを書く方が得だということをわかっていかなければならない。
  • 一度書いたコードが後々まで変更されないということはそうそうない。以下に変更を加えやすくできるかが大切
    リリース直前にリファクタリングをしてはいけない(他の質問で出た話)

Q.テストを書かない人を戒める方法を知りたい
  • 1回痛みをみるまで我慢……→ すでにだいぶ痛みみてるはずなんだけど
  • 「テストする時間がない」→「テストを自動化しないと時間がなくなる」という考え方を推し進める
  • 「書いてる時間がないんだよ!」という心理的な問題もありそう

Q.実装するときに気付いた新たなTODOの管理方法はありますか
  • べたにテキストファイル
  • 思いついたときにキーワード(「TODO」とか)とともにソースにコメントで書いておき、後で集める
  • 「~になってほしい」「~になるべき」ってテストケースができるときもある
  • 紙に書く。並べて書けるし、絵も簡単に描ける
  • 紙に書いておいたものをスキャンしてPDFに
  • TODOをJenkinsに登録して管理

振り返り (KPT) とまとめ

質問コーナーのあとは振り返りの時間。各自、KPTを付箋に書いて貼り出し。私が書いたのはこんな感じ。
  • K (Keep):
    TDD、ペアプロのやり方、タイミング等を知ることができたので、仕事でも実践できるようにしていく
  • P (Problem):
    ペアプロでこうした方がいいという考えが思い浮かびつつも言えないことがあった
  • T (Try):
    会社ではTDDは自分だけでやり始めた状態だが、他の開発メンバーとともに進めていきたい

他の人もいろいろ思うところを書いていたようです。
  • 「Keep:用語集便利」 → 「仙台に向かってお辞儀を(ry」
  • 「Problem:毎回男臭い」 → 「スタッフがみんな非リア充で(ry」
  • 「Problem:スイーツ不足」 → 「前回は余ってしまって(ry」
  • 「Problem:gitのcommitがうまくできなかった」 → 「SCMBCといういうものが(ry」
  • 「Try:テスト駆動開発入門を写経」(書いてる人が比較的多かった)

かつてのTDDBCではt_wada賞というものがあって、最近はなくなっていたらしいのですが、それを今回復活させたらしいです。
そしてなんと、私達C++のペアが t_wada賞をいただくことになりました…!
賞品として『Gitポケットリファレンス』をいただき、大鷲さんとのじゃんけん決戦の末、私がいただきました! 和田さん、ありがとうございました。

TDDBCなのにTDD関連の書籍じゃなくてGitリファレンスなんだとか、使ってたのgitじゃなくてhgじゃんとかツッコミがありそうな気がしますが、そこはキニシナイ。

最後に全員で写真撮影。
たまたま、懇親会用のビール配達してくれた人にカメラのシャッターお願いして、全員集合写真となりました。


懇親会

その後は懇親会。
ピザ、おいしかったです。ピザでおなか一杯にして帰りました。

LTもいくつか。お酒入ってる状態だったのであまり詳しく思い出せそうにないかも。この辺りはだれかがまとめてくれると期待。

懇親会でのLTやその他で印象に残っているのは
  • 「お前は今まで書いたテストの個数をおぼえているのか?」
  • cucumber + selenium → 「どんだけヒーローになりたいんすか!」
  • TA = ただ歩き回りたい
  • おっぱいサイズ当てアプリでプランニングポーカーによるサイズ見積もり
    → 結果「合格」:プランニングポーカーの有効性実証
  • 深谷さん(@fukayatsu さん)が『xUnit Test Patterns』を翻訳してまとめてくれる

感想

今回のTDDBCでは非常に学ぶことが多かったです。
特に、ペアプロのやり方がさっぱりで、ペアプロってそもそもどういうものよ?って状態だったので、それを実際に体験できたのが大きかったです。また、TDDの進め方、テストを書いて仮実装して、またテスト書いて本実装して……というタイミングを学べたのも大きいです。

今後はどうにかして業務に取り入れていくことができれば…という状態。
ペアプロはちょっと難ありですが、TDD自体はこっそり自分だけ進めていくことも可能なので、それで効果を実証して他の人にも勧めていく、という方針を取っていきたいところです。

最後に、TDDBCを開催し指導してくださった和田さんや川西さんをはじめとするスタッフの皆様、私の不甲斐なさで迷惑を書けてしまっていたかもしれないペアの大鷲さん(@aetos382 さん)、そして他の参加者の皆さんに、お礼申し上げます。ありがとうございました。


リンク(現時点での参加者のブログ投稿とか)

Togetter - 2012/09/01 TDD Boot Camp 横浜 Second Season #tddbc
http://togetter.com/li/360406

TDD Boot Camp 横浜 Second Seasonにスタッフとして参加してきた #tddbc - Shinya’s Daily Report
http://d.hatena.ne.jp/absj31/20120901/1346573746

TDDBC横浜 Second Seasonに参加してきた - 全力で気まぐれ
http://d.hatena.ne.jp/STAR_ZERO/20120901/1346514990

TDDBC 横浜 Second Season でした - @yujioramaの日記
http://d.hatena.ne.jp/yujiorama/20120902/1346517108

参加者集合写真(@setoazusa さんのツイート)
https://twitter.com/setoazusa/status/242091049806356480

TDDBC横浜2nd/記録
http://devtesting.jp/tddbc/?TDDBC%E6%A8%AA%E6%B5%9C2nd%2F%E8%A8%98%E9%8C%B2

TDDBC横浜2nd/KPT
http://devtesting.jp/tddbc/?TDDBC%E6%A8%AA%E6%B5%9C2nd%2FKPT

拍手

PR

コメント


コメントフォーム
お名前
タイトル
文字色
メールアドレス
URL
コメント
パスワード
  Vodafone絵文字 i-mode絵文字 Ezweb絵文字


忍者ブログ [PR]
プロフィール
HN:
はむぱい
職業:
ソフト作ったりしてる人
Twitter
最新CM
[06/09 replica rolex oyster perpetual datejust]
[06/09 bracelets imitation cartier love]
[06/09 replica the oyster perpetual datejust]
[06/09 datejust rolex oyster perpetual]
[06/09 replica gold love bangle]
カレンダー
06 2017/07 08
S M T W T F S
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
ブログ内検索
あ~いい漢字