いつでも聞けるTDD入門

@KYON-MM- TDDBC IN NAGOYA #2 - 2014/05/18

0

TABLE OF CONTENTSTDDBCへようこそ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を導入したプロジェクトで類似プロジェクトとの比較

IBMDriver

MSWindows

MSMSN

MSVisualStudio

Product(KLOC) 41.0 6.0 26.0 155.2Test(KLOC) 28.5 4.0 23.2 60.3非採用プロジェクトとの欠陥密度比較

0.61 0.38 0.24 0.09

実装の追加工数 15 -20%

20 - 35% 15% 20 - 25%

Realizing quality improvement through test driven development:results and experiences of four industrial teams Nachiappan

Nagappan &E. Michael Maximilien & Thirumalesh Bhat &LaurieWilliams

6.2 各種レポートのまとめ複数の論文、レポートで言われているTDDの効果をまとめて

項目別に比較

※項目別にレポートによって対象外あり

よい効果,変化なし 悪い効果バグ 7 1外部品質 9 0カバレッジ 11 0生産性 9 3Effects of Test-Driven Development: A Comparative Analysis of

Empirical Studies Simo Mäkinen and Jürgen Münch

6.3 初級者と熟練者の違い「テストを先に書くテストファースト」と「テストを後から

書くテストラスト」のどちらを選びたいか等を比較

熟練者 : テストファーストをしたい人は6割以上初級者 : テストファーストをしたい人は2割未満

An Empirical Evaluation of the Impact of Test-DrivenDevelopment on Software Quality By Copyright 2006 David

Scott Janzen

7 TDDと共に学ぶ

7.1 TDDを学ぶ(1)(2)(3)

テスト駆動開発入門テスト駆動開発実践入門Clean CodeSpecification By ExampleBDD in Action

@IT連載の「いまさら聞けないTDD/BDD超入門」@IT連載の「いまさら聞けないTDD/BDD超入門」@IT連載の「いまさら聞けないTDD/BDD超入門」

7.2 綺麗なコードを学ぶClean CodeCode Completeリーダブルコード

7.3 既存コードとの接し方を学ぶテストがないプロダクトや、保守性の低いプロダクトでTDD

する

リファクタリングレガシーコード改善ガイドデータベースリファクタリング

7.4 テストを学ぶTDDを活かすためにテストコードの保守性やテストプロセス

学ぶ

xUnit Test Patternsマインドマップではじめるソフトウェアテスト入門知識ゼロから学ぶソフトウェアテスト 【改訂版】ソフトウェアテスト実践ワークブックソフトウェアテスト技法実践アジャイルテスト

7.5 アーキテクチャを学ぶいきあたりばったりなTDDにならないようにアーキテクチャ

を学ぶ

エンタープライズアプリケーションアーキテクチャパターンエリックエヴァンスのドメイン駆動設計アナリシスパターンオブジェクトデザイン

7.6 自動化を学ぶTDDによって得られるテストやプロダクトをスムーズにビル

ドしリリースできるようにする

Jenkins継続的デリバリーGradle in ActionChef実践入門(多分良書)

7.7 バージョン管理を学ぶコードの共有、試行錯誤、機能自体の履歴管理、バグ調査、

CIをしやすくする

SCMBootCampへ！Gitポケットリファレンス入門Git入門TortoiseHg + Mercurial実用Git

8 最後にTDDをしなくても要求を満たせるようになることは素晴しいことです。ですが、あなたが持っている要求の情報、分析結果、設計スキル、実装スキルが不足しているとき。そしてそのソフトウェアを保守する未来の誰かがそれに見合わないときはおそらくTDDが最良の選択であることは非常に多いでしょう。Have a Good Development!