[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
SlideShare a Scribd company logo

いつでも聞けるTDD入門 #TDDBC_NAGOYA

•
•
kyon mm
kyon mm

2014/05/18 TDDBootCamp in Nagoya でkyon_mmが基調講演に使用したスライドです。org-mode -> reveal.js -> pdfで変換したのでアニメーションは切られています。BDDようそ

1 of 51
Downloaded 47 times
いつでも聞ける TDD入門 @KYON-MM - TDDBC IN NAGOYA #2 - 2014/05/18 0
TABLE OF CONTENTS TDDBCへようこそ TDDの基本 プロフェッショナルな話 TDDによる良い開発 BDDという存在 エンピリカルな話 TDDと共に学ぶ 最後に
1 TDDBCへようこそ 本日はTDDBootCampへ参加してくださってありがとう！ まずはTDDBootCampがどんなものかを説明します！
1.1 TDDBCで得られるもの TDDBootCamp(TDDBC)はTDD(テスト駆動開発)の考え方を聞 いて、実際にやってみるイベントです。 TDDBCを終える と、なんらかの形でTDDを自ら学習、試行錯誤、実践ができ るだけの基礎体力がつきます。
1.2 TDDBCの方向 TDDって言葉を知らなくてもTDDを試行錯誤できること TDDを学ぶ知の高速道路を提供すること 注意：TDDBCで提供できることは基本的なことや一例でしか ありません。
1.3 TDDBCのプログラム 熟練者による概念や基本の講演 参加者が実際にTDDでプログラミング TAによるTDDへのサポート 参加者からの質問にTAが答える
1.4 TDDBCをまとめると TDDBCはTDDを身に付けるための基礎体力をつけられます。 日本各地で有志によって開催されているとてもなごやかなイ ベントです。 今日はぜひ楽しんでいってください。
2 TDDの基本
2.1 TDDの言葉 プロダクトコード：これからつくるソフトウェアのコード のこと。 テストコード：ソフトウェアを実際に動作させて検証する コードのこと。 RED : テストコードが失敗している状態のこと。 GREEN: テストコードが成功している状態のこと。 REFACTOR(リファクタリングする) : コードを綺麗にするこ と。
2.2 TDDの原則や手順 基本は下の手順を繰り返す。 要求されていることを分解して再構築する。 分解した要求をテストコードで表現する。 テストコードを実行してREDになることを確認する。 テストが成功するようにプロダクトを実装する。 テストコードを実行してGREENになることを確認する。 テストコードが成功しているなら、リファクタリングす る。
2.2.1 TDDの状態遷移
2.2.2 より大きなTDDの状態遷移
2.2.3 KENT BECK SAYS… 自動テストが失敗した場合だけ、新しいコードを書く。 重複を取り除く。 2つの規則はプログラミングのタスクにおける順番を意味 する。 レッド：動作しないテストを少しだけ作成する。おそらく 最初はコンパイルできない グリーン：テストをすぐに動作させる。そのためには、ど のようなコードでもよい リファクタリング：テストを動作させるためだけに作成さ れた重複を全て取り除く
2.2.4 UNCLE BOB SAYS… 3つの原則を守りながら実装を進める。 失敗するテストができるまでプロダクトを書いてはいけな い 失敗するテストがある場合にはそれ以上テストを追加して はいけない テストを成功させるプロダクトがある場合にはそれ以上プ ロダクトを追加してはいけない
2.3 TDDは何であって、何ではないか
2.3.1 KENT BECK SAYS… 「TDDとは分析技法および設計技法であり、実際には開発全 てのアクティビティを構造化するための技法である。」
2.3.2 UNCLE BOB SAYS… 「TDDは魔法や宗教ではない。3原則に従ってもひどいコー ドを書くことはできる。TDDをすることで害が大きい場合に おいてでさえもTDDをするのはプロではない。」
2.3.3 TDDの状態遷移
2.3.4 TDDとは TDDとはソフトウェア開発の優れたフレームワークであ る。 TDDとはこれから作るべきものをまずはテストコードとし て書いてみる。 TDDを宗教にしてしまうのはいつもユーザーである。
2.4 TDDの大切なこと 自分がすぐに出来そうなものまで要求を分解、再構築して サイクルを回す 分解前の要求を満たすことも忘れずに プロダクトコードを書く前に設計をテストコードとして書 いて、プロダクトコードを書く。 テストが成功したら、失敗するテストコードを書いて、新 しいプロダクトコードを書く。 テストが成功しているときだけリファクタリングする。 短かいサイクルで回せないときは立ち止まる。 作るものの大きさが違えば使う立場も変わってくる。その 立場でテストを表現する。
3 プロフェッショナルな話
3.1 TDDを実践するということ TDDを実践することは、ほとんどの場合において「プログ ラマーとして当然のことである」と考えてよいです。 それはあなたが毎日顔を洗うことと変わりません。 ただ、どのような洗顔がいいのかが個々人で異なるよう に、あなたのスキルセット、そしてプロジェクトによって 最適なものは違うのです。 最適なものを探す上で基本に忠実であること、そして幅広 い知識はとても大切です。
3.2 TDDがもたらすこと 「曖昧で実行できない自然言語だけの意図を煩雑にも確認 していく日々」から「明確で実行できる意図を何度も簡単 に確認していく日々」へ。 「主観的な進捗確認」から「客観的な進捗確認」へ。 「動作に自信のないコード」から「つまらない確認不足の ないコード」へ。
4 TDDによる良い開発 ここではkyon_mmの経験の中からおそらくは多くのTDD熟練 者から共感してもらえそうな内容を紹介します。
4.1 TDDの状態遷移
4.2 分析、設計 ソフトウェア開発では自分がこれからつくるべきもの達の 関連や詳細を分析し、再構築し、設計します。 TDDではその分析や設計のアウトプットとしてテストコー ドを使い、実際に実装をしていき、設計と適合しているか を確かめ、ソフトウェアをイテレーティブに成長させてい きます。 机上の分析や設計もとても大切ですが、TDDをすすめいく と、その設計内容が現在のプロダクトとどのように乖離し ているかがすぐにわかるようになります。 実行可能で生きたドキュメントをつくりながら開発をして いく手法。それがTDDです。
4.3 確実な成果に結びつける TDDでは進捗80%というのはありません。例えば次の2点が ポイントになります。 設計をテストに表現できたか？ どのテストが通っているか？
4.4 機敏に感じとる
4.4.1 なかなかGREENにならないとき あなたの作業単位は大きすぎる可能性があります。REDに しているテストを変更前に戻して、もとの要求を再び分 解、再構築してテストにしましょう。 あなたのコードが汚ない可能性があります。REDにしてい るテストを変更前に戻して、プロダクトコード、テストコ ードをリファクタリングしましょう。
4.4.2 機敏の尺度 RED -> GREEN-> REFACTORのサイクルでどれくらいの時間 がかかったときに「立ち止まるべきか」の目安。 初級者 : 10分 中級者 : 5分 上級者 : 1分
5 BDDという存在 BDD = Behavior Driven Development
5.1 BDDとは テストコードに書くのは「対象の振舞いである」とする手 法です。 手順や原則やガイドは基本的に今迄説明したものと変わら ないです。
5.2 TDDの状態遷移
5.3 TDDとBDDに違いはない 根本的にTDDとBDDは違わず、それまでのTDDの語彙では 伝わりにくかった部分を言い換えたり、テンプレートを与 えることで幾分かハードルを下げるという役割を持ってい ます。 「TDDツール」や「BDDツール」という表現があります が、あくまで「BDDをしやすいテスティングフレームワー ク」というくらいです。
5.4 振舞いとはなにか 振舞いとは「【対象(つくろうとしているもの)】における 『何らかのイベント』にひも付く外部から見える変化」のこ とです。 イベントは対象によって変わります。 「【関数】に対する『入力』出力」 「【オブジェクト】の『メッセージング』」 「【画面】の『操作／表示』」 「『時間の経過』による変化」
5.5 なぜ振舞いを書くのか Dan Northは次のような言葉を残しています。 表現力のあるテスト名は失敗したときに役に立つ。 バグを埋め込んでしまった。悪い子だ。解決法：バグを直 す 意図された振る舞いは変わらず関連性があったが、どこか 別の場所に移されていた。解決法：テストを移動し、場合 によっては変更する 振る舞いがもはや正しくない。システムの前提が変わって しまっている。解決法：テストを削除する – BDDの導入 -Dan North
5.6 振舞いを書くとは 「どんな対象であるか」「対象が何をするのか」についてよ り言及できているものが「表現力がある」といえます。 「対象の振る舞いを記述する」ことについてソフトウェアか ら離れて例を出します。 例えば、あなたが友人や親や配偶者 や子供が普段どのようであるかを説明するときに何と答える でしょうか？
5.7 振舞いの記述の良い例と悪い例 「歩くことができる」「手を握り返せる」「信号の区別が 付く」「笑う」 「晴れている日に一緒に歩いていると、赤信号で止まった ときに笑いながら手を強く握り返してくる」 後者が説明的で実例としての振る舞いを表現しているのに 対して、前者はどのような人であるかは想像が難しいので す。前者は振舞いを書いているとは言い難いでしょう。
6 エンピリカルな話 エンピリカル = (実証的。経験的データに基づいた。)
6.1 MS,IBMなどの事例 TDDを導入したプロジェクトで類似プロジェクトとの比較 IBM Driver MS Windows MS MSN MS VisualStudio Product(KLOC) 41.0 6.0 26.0 155.2 Test(KLOC) 28.5 4.0 23.2 60.3 非採用プロジェクトと の欠陥密度比較 0.61 0.38 0.24 0.09 実装の追加工数 15 - 20% 20 -35% 15% 20 -25% Realizingqualityimprovementthrough testdriven development: results and experiences of four industrialteams Nachiappan Nagappan &E. MichaelMaximilien &Thirumalesh Bhat&Laurie Williams
6.2 各種レポートのまとめ 複数の論文、レポートで言われているTDDの効果をまとめて 項目別に比較 ※項目別にレポートによって対象外あり よい効果,変化なし 悪い効果 バグ 7 1 外部品質 9 0 カバレッジ 11 0 生産性 9 3 Effects of Test-Driven Development: AComparative Analysis of EmpiricalStudies Simo Mäkinen and Jürgen Münch
6.3 初級者と熟練者の違い 「テストを先に書くテストファースト」と「テストを後から 書くテストラスト」のどちらを選びたいか等を比較 熟練者 : テストファーストをしたい人は6割以上 初級者 : テストファーストをしたい人は2割未満 An EmpiricalEvaluation of the Impactof Test-Driven Developmenton Software QualityByCopyright2006 David ScottJanzen
7 TDDと共に学ぶ
7.1 TDDを学ぶ (1) (2) (3) テスト駆動開発入門 テスト駆動開発実践入門 Clean Code Specification ByExample BDD in Action @IT連載の「いまさら聞けないTDD/BDD超入門」 @IT連載の「いまさら聞けないTDD/BDD超入門」 @IT連載の「いまさら聞けないTDD/BDD超入門」
7.2 綺麗なコードを学ぶ Clean Code Code Complete リーダブルコード
7.3 既存コードとの接し方を学ぶ テストがないプロダクトや、保守性の低いプロダクトでTDD する リファクタリング レガシーコード改善ガイド データベースリファクタリング
7.4 テストを学ぶ TDDを活かすためにテストコードの保守性やテストプロセス 学ぶ xUnitTestPatterns マインドマップではじめるソフトウェアテスト入門 知識ゼロから学ぶソフトウェアテスト 【改訂版】 ソフトウェアテスト実践ワークブック ソフトウェアテスト技法 実践アジャイルテスト
7.5 アーキテクチャを学ぶ いきあたりばったりなTDDにならないようにアーキテクチャ を学ぶ エンタープライズアプリケーションアーキテクチャパター ン エリックエヴァンスのドメイン駆動設計 アナリシスパターン オブジェクトデザイン
7.6 自動化を学ぶ TDDによって得られるテストやプロダクトをスムーズにビル ドしリリースできるようにする Jenkins 継続的デリバリー Gradle in Action Chef実践入門(多分良書)
7.7 バージョン管理を学ぶ コードの共有、試行錯誤、機能自体の履歴管理、バグ調査、 CIをしやすくする SCMBootCampへ！ Gitポケットリファレンス 入門Git 入門TortoiseHg+ Mercurial 実用Git
8 最後に TDDをしなくても要求を満たせるようになることは素晴し いことです。 ですが、あなたが持っている要求の情報、分析結果、設計 スキル、実装スキルが不足しているとき。 そしてそのソフトウェアを保守する未来の誰かがそれに見 合わないときはおそらくTDDが最良の選択であることは非 常に多いでしょう。 Have aGood Development!

More Related Content

いつでも聞けるTDD入門 #TDDBC_NAGOYA