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

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

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

by kyon_mm Mm

on May 21, 2014

Statistics

Views

Actions

0 Embeds 0

Accessibility

Categories

Upload Details

Usage Rights

Report content

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