• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
いつでも聞けるTDD入門 #TDDBC_NAGOYA
 

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

on

  • 4,670 views

2014/05/18 TDDBootCamp in Nagoya でkyon_mmが基調講演に使用したスライドです。org-mode -> reveal.js -> ...

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

Statistics

Views

Total Views
4,670
Views on SlideShare
4,478
Embed Views
192

Actions

Likes
31
Downloads
28
Comments
0

3 Embeds 192

https://twitter.com 186
http://s.deeeki.com 5
https://tweetdeck.twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

    • いつでも聞ける 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!