Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
TDD BootCamp
in JJUG CCC
2014.05.17 JJUG CCC 2014 Spring
Shuji Watanabe (@shuji_w6e)
1
#ccc_r53 #jjug_ccc
https://github.c...
自己紹介
渡辺 修司 / @shuji_w6e
札幌Javaコミュニティ
やさしいデスマーチ
JUnit実践入門
Java, Groovy, JavaScript, AWS, TDD
ロードバイク, スノーボード, トレラン
NEW
4刷!

累計1万部
最近のお仕事...
昨年8月に転職
株式会社クラスメソッド
札幌にて在宅勤務
AWS利用者向けシステムの開発
主にフロントエンドや自動化などを担当
Spring, Ember.js, d3-data
ブログ業務
クラスメソッド札幌オフィス開設!
AWSエンジニア / iOSエンジニア
U/Iターン歓迎!
7月初旬	

開設予定!
アプリ屋から	

移籍可能
Special Thanks TA
@i_takehiro
@grimrose
@sue445
@setoazusa
@torazuka
@uasano
@yujiorama
TDDBCへ
ようこそ
http://devtesting.jp/tddbc/
TDD Boot Camp(TDDBC) とは、テスト
駆動開発(Test Driven Development)につ
いて、座学だけでなく、実習形式で手を
動かして体得することを目的とす...
ショートバージョン
2時間しかないのでダイジェストで!
TDDとは?
TDDは死んだ?
レガシーコード体験
レガシーコード改善
モデリング
ユニットテストハンズオン
本家TDDBCとの違い
ショートバージョン(本家は1日)
ペアプログラミングは行わない
レビュー大会は行わない
テストファーストに拘らない
プロダクションコードは8分組み
レガシーコードからTDDを体験する
テスト駆動開発とは?
テスト駆動開発とは?
ソフトウェアの開発手法
テスト駆動開発の1サイクル
はじめにテストコードを書く
テストが成功する必要最低限のコードを書く
テスト成功を維持してリファクタリングする
上記サイクルを素早くテンポ良く繰り返す
1.設計する
2....
TDDのサイクル
1.設計する
2.テストを書く
3.コードを書く
4.テストを成功させる
5.リファクタリング
Heuristics
TDD 品質保証テスト
品質保証テストはソフトウェアを対象とし、
品質担当者が高い品質を担保するために実施
TDDは品質を担保するわけではない
結果的に品質は高まるが主目的ではない
開発者が安心して開発できるための開発手法
TDDは設計やプログ...
汚いコードは動かない
密結合
多重ネスト
巨大なクラス
多すぎる引数
多すぎる責務
http://www.flickr.com/photos/peakman2/1017866785/
レガシーコード!
レガシーコード生成のプロセス
1. 最初の仕様でコードを書く
2. 追加機能で増築する
3. 仕様変更で改築する
4. 似たような機能はコピペして作る
5. これらのプロセスが秘伝のタレとなる
http://www.flickr.com/photos/jas_132/5403388208
TDDで解決?
レガシーコードへの道
設計
きれいな動くコードへの道
動かない 動く
きれい
汚い
1.設計する
動かない 動く
きれい
汚い
1.設計する
2.テストを書く
3.コードを書く
4.テストを成功させる
5.リファクタリング
Heuristics
2.テストを書く
動かない 動く
きれい
汚い
1.設計する
2.テストを書く
3.コードを書く
4.テストを成功させる
5.リファクタリング
Heuristics
3.コードを書く
動かない 動く
きれい
汚い
1.設計する
2.テストを書く
3.コードを書く
4.テストを成功させる
5.リファクタリング
Heuristics
4.テストを成功させる
動かない 動く
きれい
汚い
1.設計する
2.テストを書く
3.コードを書く
4.テストを成功させる
5.リファクタリング
Heuristics
5.リファクタリング
動かない 動く
きれい
汚い
1.設計する
2.テストを書く
3.コードを書く
4.テストを成功させる
5.リファクタリング
Heuristics
1.設計する
動かない 動く
きれい
汚い
1.設計する
2.テストを書く
3.コードを書く
4.テストを成功させる
5.リファクタリング
Heuristics
TDDのポイント
テストを意識した設計(テストファースト)
テストによる安心
リファクタリング
イテレーティブな開発サイクル
TDDのこころ
©和田卓人
小さく  
個別に  
すばやく
ひとつずつ、一歩ずつ
小さなステップで
大きなものは小さく分割
確実に、堅実に
手戻りを小さく
ひとりずつ、仕留める
テストは個別撃破する
次のテストを作らない
すばやくまわす
小さく回す
早く回す
すぐに対応
リズム重要
1.設計する
2.テストを書く
3.コードを書く
4.テストを成功させる
5.リファクタリング
Heuristics
使う  
作る  
伝える
自分が最初のユーザー
使いにくいものは使いにくい
自分で評価する
納得できるか?
恥ずかしくないか?
解りやすいか?
道具にこだわる
最高のパフォーマンスを維持する
プロとしてのこだわり
少しでも使いやすく
日々、研究・工夫
未来の自分が読む
テストコードは保守される
読みにくいコードは悪
シンプルに
名前重要
型
どうして、  
テスト駆動開発を  
導入するのか?
http://www.flickr.com/photos/yopse/3772030400/
不安
スキル不足
複雑な要件
仕様変更
経験不足
http://www.flickr.com/photos/32010000@N08/2987901256/
安全を確保する
なぜ、TDDを実践するか?
ソフトウェアは思った以上に複雑
パーフェクトプログラマなんかいない
不安だからユニットテストを書く
セーフティネットとしてのユニットテスト
すばやく回し、すばやいフィードバック
TDDが目指すところ
安心できる健康な開発
変更に強い健康なコード
テスト駆動開発は死んだ?
http://www.flickr.com/photos/palermobootcamp/5464512672/
TDD!TDD!
テストファースト!
TDDは死んだ、無益だ!
http://www.flickr.com/photos/bsom/4625185702/
貴様のプロジェクトでは、
効果的なテストをしてるか?
TDDが無益とか有益とか語る前に...
(ユニット)テスティングできてますか?
テストファーストはテクニックのひとつ
TDDはユニットテストを学ぶ教科書
常時TDDをやる必要もありません
TDDの考え方を学ぶ価値は大きくあります
Long live testing
going with the practice of testing

where no testing had happened before
レガシーコード体験
NO TESTING
レガシーコードを読んでみよう
よくない点を列挙してみよう
どうしてそうなったのかを想像してみよう
5∼10分したらディスカッションします
気になった部分(1)
コンストラクタで在庫決め打ちいいの?
シングルトン
フィールド名とか日本語(ローマ字)が気持ち悪い
注文メソッドが色々やりすぎ
過去の編集履歴
税率がハードコーディング
Integerとintが混在
「なんでマイナス?」
気になった部分(2)
全体1クラス
スレッドセーフでない
ジェネリクスが使われていない
ロガーが使われていない
例外処理
JavaDocがあったりなかったり
値の検査がないのでマイナス在庫?
レガシーコード改善
ユニットテストを活用した改善
対象をテストで保護し(仕様化テスト)、
リファクタリングしていく
レガシーコード仕様化テスト
クラス
クラス
クラス
クラス
ユニットテスト
http://www.flickr.com/photos/alisdair/2398525854/
やって

られっか!?
仕様化テストだけで大変
テストできない部分も多い
コードが複雑でクラス化難しい
そもそもバグが...
辛い、ただ辛い
汚いコードは動かない
密結合
深いネスト
巨大なクラス
多すぎる引数
多すぎる責務
綺麗なコードは変更に強い
疎結合
浅いネスト
小さなクラス
適度な引数
適度な責務
http://www.flickr.com/photos/k1netik/50298297/
設計麻痺に注意
モデリング

+
テスト駆動開発
モデリング
モデリングとは?
要求(業務)をモデルに抽象化すること
As-Is から To-Be へ
大雑把に言えば「設計」
概要を掴むための荒いモデリング
詳細を詰めるための詳細なモデリング
特定の目的のためのモデリング
ドメインモデリング
業務ドメインでの主要データ
静的モデル
クラス図の基盤
Is-A
Has-A *
1
xxx
xxx
xxx
xxx
xxx
*
1
xxx
*
1
*
1
ドメインモデリングの目的
問題領域を把握するため
用語を統一するため
ユースケースを作成する基盤とするため
静的な設計のスタート地点とするため
汎化と集約
汎化(Is-A)と集約(Has-A)を使う
他の細かい関係は重要ではない(今は)
用語整理と問題領域の理解が目的
95%はカバーできる
参考)システム境界
システムと外部との接点
どこからがシステムの機能・データなのか?
ユーザーインターフェイス(画面)
外部インターフェイス
ユーザ
システム境界
システム
外部システム
機能 データ
参考)入出力(なにを)
入力
ファイル、フォームデータ
出力
画面、帳票、ファイル
システム境界
システム
入力
出力
モデリングの例
ざっくりと単語(名詞)を抽出
モデリングの例
属性などを追加していく
Enjoy Testing!
ハンズオンの進め方
ひとつのメソッドを選んでテストしてみよう
テストケースを増やす?
別のメソッドをテストを書く?
仕様変更する?
上から下まで通すテストを書く?
TAに相談してみよう!
TDD BootCamp in JJUG CCC - レガシーコード対策編 -
Upcoming SlideShare
Loading in …5
×

TDD BootCamp in JJUG CCC - レガシーコード対策編 -

4,693 views

Published on

JJUG CCC 2014 Soringで行ったユニットテストハンズオンでの資料です。

Published in: Technology
  • Be the first to comment

TDD BootCamp in JJUG CCC - レガシーコード対策編 -

  1. 1. TDD BootCamp in JJUG CCC 2014.05.17 JJUG CCC 2014 Spring Shuji Watanabe (@shuji_w6e) 1 #ccc_r53 #jjug_ccc https://github.com/shuji/legacy-hanbai-kanri
  2. 2. 自己紹介
  3. 3. 渡辺 修司 / @shuji_w6e 札幌Javaコミュニティ やさしいデスマーチ JUnit実践入門 Java, Groovy, JavaScript, AWS, TDD ロードバイク, スノーボード, トレラン NEW 4刷!
 累計1万部
  4. 4. 最近のお仕事... 昨年8月に転職 株式会社クラスメソッド 札幌にて在宅勤務 AWS利用者向けシステムの開発 主にフロントエンドや自動化などを担当 Spring, Ember.js, d3-data ブログ業務
  5. 5. クラスメソッド札幌オフィス開設! AWSエンジニア / iOSエンジニア U/Iターン歓迎! 7月初旬 開設予定! アプリ屋から 移籍可能
  6. 6. Special Thanks TA @i_takehiro @grimrose @sue445 @setoazusa @torazuka @uasano @yujiorama
  7. 7. TDDBCへ ようこそ
  8. 8. http://devtesting.jp/tddbc/ TDD Boot Camp(TDDBC) とは、テスト 駆動開発(Test Driven Development)につ いて、座学だけでなく、実習形式で手を 動かして体得することを目的とするイベ ントです。
  9. 9. ショートバージョン 2時間しかないのでダイジェストで! TDDとは? TDDは死んだ? レガシーコード体験 レガシーコード改善 モデリング ユニットテストハンズオン
  10. 10. 本家TDDBCとの違い ショートバージョン(本家は1日) ペアプログラミングは行わない レビュー大会は行わない テストファーストに拘らない プロダクションコードは8分組み レガシーコードからTDDを体験する
  11. 11. テスト駆動開発とは?
  12. 12. テスト駆動開発とは? ソフトウェアの開発手法 テスト駆動開発の1サイクル はじめにテストコードを書く テストが成功する必要最低限のコードを書く テスト成功を維持してリファクタリングする 上記サイクルを素早くテンポ良く繰り返す 1.設計する 2.テストを書く 3.コードを書く 4.テストを成功させる 5.リファクタリング Heuristics
  13. 13. TDDのサイクル 1.設計する 2.テストを書く 3.コードを書く 4.テストを成功させる 5.リファクタリング Heuristics
  14. 14. TDD 品質保証テスト 品質保証テストはソフトウェアを対象とし、 品質担当者が高い品質を担保するために実施 TDDは品質を担保するわけではない 結果的に品質は高まるが主目的ではない 開発者が安心して開発できるための開発手法 TDDは設計やプログラム自体を対象とする
  15. 15. 汚いコードは動かない 密結合 多重ネスト 巨大なクラス 多すぎる引数 多すぎる責務
  16. 16. http://www.flickr.com/photos/peakman2/1017866785/ レガシーコード!
  17. 17. レガシーコード生成のプロセス 1. 最初の仕様でコードを書く 2. 追加機能で増築する 3. 仕様変更で改築する 4. 似たような機能はコピペして作る 5. これらのプロセスが秘伝のタレとなる
  18. 18. http://www.flickr.com/photos/jas_132/5403388208 TDDで解決?
  19. 19. レガシーコードへの道 設計
  20. 20. きれいな動くコードへの道 動かない 動く きれい 汚い
  21. 21. 1.設計する 動かない 動く きれい 汚い 1.設計する 2.テストを書く 3.コードを書く 4.テストを成功させる 5.リファクタリング Heuristics
  22. 22. 2.テストを書く 動かない 動く きれい 汚い 1.設計する 2.テストを書く 3.コードを書く 4.テストを成功させる 5.リファクタリング Heuristics
  23. 23. 3.コードを書く 動かない 動く きれい 汚い 1.設計する 2.テストを書く 3.コードを書く 4.テストを成功させる 5.リファクタリング Heuristics
  24. 24. 4.テストを成功させる 動かない 動く きれい 汚い 1.設計する 2.テストを書く 3.コードを書く 4.テストを成功させる 5.リファクタリング Heuristics
  25. 25. 5.リファクタリング 動かない 動く きれい 汚い 1.設計する 2.テストを書く 3.コードを書く 4.テストを成功させる 5.リファクタリング Heuristics
  26. 26. 1.設計する 動かない 動く きれい 汚い 1.設計する 2.テストを書く 3.コードを書く 4.テストを成功させる 5.リファクタリング Heuristics
  27. 27. TDDのポイント テストを意識した設計(テストファースト) テストによる安心 リファクタリング イテレーティブな開発サイクル
  28. 28. TDDのこころ ©和田卓人
  29. 29. 小さく   個別に   すばやく
  30. 30. ひとつずつ、一歩ずつ 小さなステップで 大きなものは小さく分割 確実に、堅実に 手戻りを小さく
  31. 31. ひとりずつ、仕留める テストは個別撃破する 次のテストを作らない
  32. 32. すばやくまわす 小さく回す 早く回す すぐに対応 リズム重要 1.設計する 2.テストを書く 3.コードを書く 4.テストを成功させる 5.リファクタリング Heuristics
  33. 33. 使う   作る   伝える
  34. 34. 自分が最初のユーザー 使いにくいものは使いにくい 自分で評価する 納得できるか? 恥ずかしくないか? 解りやすいか?
  35. 35. 道具にこだわる 最高のパフォーマンスを維持する プロとしてのこだわり 少しでも使いやすく 日々、研究・工夫
  36. 36. 未来の自分が読む テストコードは保守される 読みにくいコードは悪 シンプルに 名前重要 型
  37. 37. どうして、   テスト駆動開発を   導入するのか?
  38. 38. http://www.flickr.com/photos/yopse/3772030400/ 不安 スキル不足 複雑な要件 仕様変更 経験不足
  39. 39. http://www.flickr.com/photos/32010000@N08/2987901256/ 安全を確保する
  40. 40. なぜ、TDDを実践するか? ソフトウェアは思った以上に複雑 パーフェクトプログラマなんかいない 不安だからユニットテストを書く セーフティネットとしてのユニットテスト すばやく回し、すばやいフィードバック
  41. 41. TDDが目指すところ 安心できる健康な開発 変更に強い健康なコード
  42. 42. テスト駆動開発は死んだ?
  43. 43. http://www.flickr.com/photos/palermobootcamp/5464512672/ TDD!TDD! テストファースト!
  44. 44. TDDは死んだ、無益だ!
  45. 45. http://www.flickr.com/photos/bsom/4625185702/ 貴様のプロジェクトでは、 効果的なテストをしてるか?
  46. 46. TDDが無益とか有益とか語る前に... (ユニット)テスティングできてますか? テストファーストはテクニックのひとつ TDDはユニットテストを学ぶ教科書 常時TDDをやる必要もありません TDDの考え方を学ぶ価値は大きくあります
  47. 47. Long live testing going with the practice of testing
 where no testing had happened before
  48. 48. レガシーコード体験 NO TESTING
  49. 49. レガシーコードを読んでみよう よくない点を列挙してみよう どうしてそうなったのかを想像してみよう 5∼10分したらディスカッションします
  50. 50. 気になった部分(1) コンストラクタで在庫決め打ちいいの? シングルトン フィールド名とか日本語(ローマ字)が気持ち悪い 注文メソッドが色々やりすぎ 過去の編集履歴 税率がハードコーディング Integerとintが混在 「なんでマイナス?」
  51. 51. 気になった部分(2) 全体1クラス スレッドセーフでない ジェネリクスが使われていない ロガーが使われていない 例外処理 JavaDocがあったりなかったり 値の検査がないのでマイナス在庫?
  52. 52. レガシーコード改善
  53. 53. ユニットテストを活用した改善 対象をテストで保護し(仕様化テスト)、 リファクタリングしていく レガシーコード仕様化テスト クラス クラス クラス クラス ユニットテスト
  54. 54. http://www.flickr.com/photos/alisdair/2398525854/ やって
 られっか!?
  55. 55. 仕様化テストだけで大変 テストできない部分も多い コードが複雑でクラス化難しい そもそもバグが... 辛い、ただ辛い
  56. 56. 汚いコードは動かない 密結合 深いネスト 巨大なクラス 多すぎる引数 多すぎる責務
  57. 57. 綺麗なコードは変更に強い 疎結合 浅いネスト 小さなクラス 適度な引数 適度な責務
  58. 58. http://www.flickr.com/photos/k1netik/50298297/ 設計麻痺に注意
  59. 59. モデリング
 + テスト駆動開発
  60. 60. モデリング
  61. 61. モデリングとは? 要求(業務)をモデルに抽象化すること As-Is から To-Be へ 大雑把に言えば「設計」 概要を掴むための荒いモデリング 詳細を詰めるための詳細なモデリング 特定の目的のためのモデリング
  62. 62. ドメインモデリング 業務ドメインでの主要データ 静的モデル クラス図の基盤 Is-A Has-A * 1 xxx xxx xxx xxx xxx * 1 xxx * 1 * 1
  63. 63. ドメインモデリングの目的 問題領域を把握するため 用語を統一するため ユースケースを作成する基盤とするため 静的な設計のスタート地点とするため
  64. 64. 汎化と集約 汎化(Is-A)と集約(Has-A)を使う 他の細かい関係は重要ではない(今は) 用語整理と問題領域の理解が目的 95%はカバーできる
  65. 65. 参考)システム境界 システムと外部との接点 どこからがシステムの機能・データなのか? ユーザーインターフェイス(画面) 外部インターフェイス ユーザ システム境界 システム 外部システム 機能 データ
  66. 66. 参考)入出力(なにを) 入力 ファイル、フォームデータ 出力 画面、帳票、ファイル システム境界 システム 入力 出力
  67. 67. モデリングの例 ざっくりと単語(名詞)を抽出
  68. 68. モデリングの例 属性などを追加していく
  69. 69. Enjoy Testing!
  70. 70. ハンズオンの進め方 ひとつのメソッドを選んでテストしてみよう テストケースを増やす? 別のメソッドをテストを書く? 仕様変更する? 上から下まで通すテストを書く? TAに相談してみよう!

×