読者です 読者をやめる 読者になる 読者になる

コンユウメモ

技術メモを忘れるのでBlogでメモ

TDD Boot Camp Tokyo2013/07/27 に参加してTDD教に入信してきた #tddbc

rspec ruby tdd

TDD Boot Camp Tokyo@楽天 品川シーサイド

テスト駆動開発(以下TDD)http://devtesting.jp/tddbc/を実際に合宿的に1日で勉強しましょうという勉強会に参加してきた。

すごくためになったのでここに振り返りの意味も込めて記載する。これを読んで参加する人が増えたらなと切に願う。

TDDの説明の座学と、ペアプログラミングで実践する2部構成

Keynote @t_wada

@t_wadaこと和田さんは国内ではTDDの伝道師な存在

2007年と少し古いけど、和田さんが動画で解説してくれているものもある。 gihyo.jp テスト駆動開発講座http://gihyo.jp/dev/serial/01/tdd

以下keynoteの内容を抜粋

TDD Boot Campのブートキャンプとは、短期間で一人前の兵士になる訓練

TDDとは以下のリリースに対する不安を取り除くもの

  • 複雑さに関するおそれと不安
  • 不安を克服する技術の不足

テスト駆動開発入門の中でこう書かれている

「動作するきれいなコード」動作するきれいなコードはあらゆる理由で価値がある。

テスト駆動開発入門 TDDのバイブル。

テスト駆動開発入門

テスト駆動開発入門

  • 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2003/09
  • メディア: 単行本
  • 購入: 45人 クリック: 1,058回
  • この商品を含むブログ (159件) を見る

良い設計綺麗な設計から動作するコードへ落としこむのは難しい

コードを書いてみたらわかることがたくさんある

意外と難しいとか、設計では速度に問題があるとかetc

予測が立ちにくい

動作する汚いコードから綺麗なコードにリファクタリングするほうが良い

TDDとはテストコードとプロダクトコードを同時に書きながら開発を行なっていく手法

具体的な開発手法として、

  1. 簡易的にやることを決める、その目標を示すテストを書く
  2. そのテストを実行して失敗させるRed
  3. 目的のコードを書く→動けばいいコードを書く、テストが通る最小限のコードを書く
  4. 書いたテストを成功させるGreen
  5. コードをきれいにしてテストが通るまでリファクタリングを行う Refactor

2~4を繰り返し、また次の目標のテストを書く

リファクタリングは大事、テストが通るだけではダメ

一つ一つのアクティビティ(メソッドの実装)には必ずリファクタリングを入れて負債を無くする。あとから修正しようと思うと、大変。

リファクタリングで参考になる書籍

リーダブルコード

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リファクタリング プログラミングの体質改善テクニック

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

  • 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/05
  • メディア: 単行本
  • 購入: 94人 クリック: 3,091回
  • この商品を含むブログ (301件) を見る

TDDの心得

小さい階段を少しずつ登る、段を小さくする

小さいテストをたくさん書く、タスクを分解する

複数を相手にしない、ひとりずつ対処する。(宮本武蔵 五輪書より)

一つずつの連続に落としこむ

  • 素早く回す

    • TDDは回転である
    • 回転の速度、フィードバックサイクルを細かく回す。
    • テスト2分、実装2分、リファクタリング5分など 短く早くリズムに乗って
  • 自分が最初のユーザ

    • 自分が使いやすいというものを考える
    • 引数が多すぎとか、テストを書くときにだるいからリファクタリングする
    • Each own dog food
  • 不安をテストに

    • 何に対してテストを書くのか、どれくらい書けばいいのか?→不安をテストにする どういうInputだったら不安か?
    • 問題を分解して、小さいテストを書く

自分が書いたコードが動くか動かないか不安だから→毎日テスト可能なテストがあるので、不安がなくなる

テストを同時に書くため、即座にフィードバックを得る。

そして書いたコードに自信をもつ、これから書くコードに自信をもつため

TDDの真の目的は健康

  • 変更に対応できる、綺麗な健康なコード
  • 変化に対応できる、健康体のチーム これまで書いたコードの品質が担保されてる 家に帰れる

事例

MSとIBM,エリクソンTDDの導入効果論文

  • 品質は上がる 欠陥が減る 7割減
  • コード実装時間は20%増える
  • 開発工数を抑えると50%という意見も上がった
    • 実装工数が増えているのに理由はデバッグする時間が減るからだと考えられる

TDD応用 問題別 書籍紹介

テストの無いコードがすでにたくさんある

レガシーコード改善ガイド

  • テストの書きにくいコードを書いていくには?
  • 既存のテストがないコードがたくさんある

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

  • 作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義
  • 出版社/メーカー: 翔泳社
  • 発売日: 2009/07/14
  • メディア: 大型本
  • 購入: 45人 クリック: 673回
  • この商品を含むブログ (145件) を見る

既にデータの入ったデータベースはどう修正するか?

データベースリファクタリング

データベース・リファクタリング

データベース・リファクタリング

  • 作者: スコット W アンブラー,ピラモド・サダラージ,梅澤真史,越智典子,小黒直樹
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2008/03/26
  • メディア: 単行本
  • 購入: 10人 クリック: 211回
  • この商品を含むブログ (49件) を見る

テストコードのリファクタリング

  • Fragile Tests 変なテストを書いてないかい
  • Slow Tests 遅いテスト
  • DB,Network,Filesystemに対するテスト xUnit Test Patterns 洋書 

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

xUnit Test Patternsはほぼ著者のWikiにある xUnit test patterns wiki http://xunitpatterns.com/

上記の読書会まとめ 日本語http://devtesting.jp/pekema/

結局どこまでテストすればいいのか?

ソフトウェアテスト技法ドリル 

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

マルチスレッドなど複雑なプログラムはどうしたらいいの?

実践テスト駆動開発 

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION)

この著者のスティーブさんがサプライズゲストに来てくれた、プレゼンしてくれたり TDDで同じ課題をやってくれたりした。

喋ってる英語の3割ぐらいしかわかんなかったけど。

TDDはスキルです練習すればうまくなる

午前中のKeynoteはこんな感じで終わり、昼休憩には弁当付きで行われた。

TDDデモ ペアプログラミング

お題 Fizz Buzz問題

Fizz Buzz問題元 Coding Horror: Why Can't Programmers.. Program?

アオキさんによる日本語訳 どうしてプログラマに・・・プログラムが書けないのか?

問題を少タスクに分けるたり、メソッド名やクラス名を相談しながら作成して行く様はまさにペアプログラミングのお手本のようであった。

かなりじっくり話しながら作るので、時間がかかりそう。

ペアプロお題

各言語に別れて、ペアを組みペアプログラミングのお題に取り組んだ。

  • 1時間プロ
  • 数組のペアが前に出て発表

と言うのを二回繰り返した

お題 飲み物自動販売機 V2.0 http://devtesting.jp/tddbc/?TDDBC%E5%A4%A7%E9%98%AA3.0%2F%E8%AA%B2%E9%A1%8C

実践テスト駆動開発のSteve Freeman さんが書いた自販機のコードはこちら tddbc/jpy_tdd · GitHub

ペアの方とのペアプロの方法

1台のマシンをパスするのではなくGithub上にリポジトリを作って共用した。

ただPullRequestでマージするのは面倒だったのでコミット権限を付与して、それぞれコミットしてmasterブランチにPushする方式とした。

感想

自分はRuby(Rspec) で参加、最近ずっとUnityばっかりだったのでRubyを忘れていた。

ペアプロをこんなに長い時間やったのは初めてだった。初対面の人とペアプロをやったというのもあるが、かなり時間がかかる。

実際の業務ならMVCのモデルの作成なら、システム全体の影響範囲が大きいから良さそう。ビューとコントローラはコードレビューで良いかなと思った。

運営の雰囲気は、学校祭のパソコン部と言う感じかな

みなさんボランティアなのにちゃんとしていてありがたい。運営並びにTAのみなさんありがとうございました。