TDDはじめて物語Second Season(updated)

Copyright 2017 Hiroyuki Onaka
TDDはじめて物語
Second Season(updated)
2017/11/2
大中浩行
この作品はクリエイティブ・コモンズ表示 4.0 国際ライセンスの下に提供されています。

突然ですが、ここで問題です
平成28年春期応用情報技術者試験(午前) より
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2016h28_1/2016h28h_ap_am_qs.pdf

正解は、こちら

By National Photo Company [Public domain], via Wikimedia Commons
https://en.wikipedia.org/wiki/Bulletproof_vest
テストファースト

では、「テストファースト」とは...?
今日は「テストファースト」をはじめとして、
TDDとは何かについて学んでいきましょう

アジェンダ
• ソフトウェア開発を巡る状況
• TDDとは
• TDDの構成要素
• テストファーストとは
• きれいなコード
• どうテストするか
• 明日から役立つお役立ち情報
• なぜTDDするのか

ソフトウェア
開発を巡る状
況

http://www.itmedia.co.jp/news/articles/1708/28/news086.html

「99%の信頼性を持つスマートフォンを使って
いるユーザーには、サービスの信頼性99.99%
の場合と、99.999%の場合との違いは分からな
いのです。」
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy.
澤田武男、関根達夫、細川一茂、矢吹大輔(監訳) 玉川竜司(訳)
「SRE サイトリライアビリティエンジニアリング」

「スライムが強かったらバグ」
「たとえばドラゴンクエストシリーズの序盤で
対戦するモンスターのスライムが、まわりのモ
ンスターより強いようなことがあればドラゴン
クエストシリーズのお客様視点では異常です。
仕様書に書いてあったとしても指摘すべきで
す。」
青山公士「国民的RPG オンライン化へのチャレンジドラゴンクエストⅩ開発ノウハウ大公開」
(WEB+DB PRESS vol.90)

• 「品質」というものの捉え方の多様化
• バグのモグラ叩きのなかからは、多様化する
品質への要求に答えることはできない
• システム開発の成果物たるプログラムに対す
る、内部品質への要求の高まり

TDDとは

By Improve It (Flickr: Kent Beck no Workshop Mapping XP.) [CC BY-SA 2.0 (http://creativecommons.org/licenses/by-sa/2.0)], via
Wikimedia Commons
https://en.wikipedia.org/wiki/Kent_Beck
Kent Beck

TDDとは
1. まずはテストを1つ書く
2. すべてのテストを走らせ、新しいテストの失敗を確
認する
3. 小さな変更を行う
4. すべてのテストを走らせ、すべて成功することを確
認する
5. リファクタリングを行って重複を除去する
ケント・ベック(著)和田卓人(訳)「テスト駆動開発」

例題:FizzBuzz
1から100までの数をプリントするプログラムを
書け。ただし3の倍数のときは数の代わりに
｢Fizz｣と、5の倍数のときは｢Buzz｣とプリント
し、3と5両方の倍数の場合には｢FizzBuzz｣とプ
リントすること。

まずはテストを1つ書く
public class FizzBuzzTest {
@Test
@DisplayName("3の倍数の時にFizzを返すこと")
void _3の倍数の場合にFizzを返すこと() {
FizzBuzz fizzBuzz = new FizzBuzz();
assertEquals("Fizz", fizzBuzz.fizzBuzz(3));
}
@Test
@DisplayName("数をそのまま返すこと")
void 数をそのまま返すこと() {
FizzBuzz fizzBuzz = new FizzBuzz();
Assertions.assertEquals("4", fizzBuzz.fizzBuzz(4));
}
}

すべてのテストを走らせ、新しいテストの失敗を
確認する

小さな変更を行う
public class FizzBuzz {
public String fizzBuzz(int num) {
if (num % 3 == 0){
return "Fizz";
}
return Integer.toString(num);
}
}

すべてのテストを走らせ、すべて成功することを
確認する

フィードバックループ
「運転というのはね、車を正しい方向に走らせ
ることじゃないの。常に注意を払って、こっち
に行ったら少し戻して、あっちに行ったら少し
戻して、そうやって軌道修正していくものよ」
これがXP のパラダイムだ。注意して、適応して、
変更する。
Kent Beck・Cynthia Andres(著) 角征典(訳) 「エクストリームプログラミング」

TDDの構成要
素

TDDの特徴
• アサートファースト
• 仮実装・三角測量・明白な実装
• リファクタリング

アサートファースト
何から「テストファースト」をはじめるか
→ テストが最終的に確認すべき結果(アサー
ション)から書き始める

仮実装・三角測量・明白な実装
• 仮実装
アサーションを書いた後、アサーションを通
すための必要最小限の実装を行う。
• テストの正当性を検証するため(テストのテスト)
• テストから最短距離でフィードバックを得るため

仮実装・三角測量・明白な実装
• 三角測量
仮実装から本実装を引き出す際に、二つのテ
ストケースを重ね合わせて実装を導き出す

• 明白な実装
テストケースから本実装を明確にイメージで
きるときに、テストケースを安全網にして、
直接実装する

必要となるフィードバックの度合いに応じて、
「仮実装・三角測量・明白な実装」のどれを用
いるか使い分けていくのがポイントです。

Yu Asano「私のTDDのこころ」より
https://www.slideshare.net/uasano/agile-samuraibasecamp-tdd-keynote/43

リファクタリング
• 「コードのあるべき姿」はプログラマーがキー
ボードを叩く中であらわれる。アーキテクトが
事前にコードの理想像を示すことはできない
• 一度プログラミングしたら、そこで完成なわけ
でもない
• 「動くコードに触るな」に抗う

• 継続的にリファクタリングを続けられる、
「動くコードに手を入れられる」のが強い
チーム
• テストを安全網にすることで、リファクタリ
ングを含めて思い切って手を打つことが出来
るようになる。

テストを安全網にした事例
https://www.slideshare.net/setoazusa/move-to-java8
https://www.slideshare.net/setoazusa/jjug-ccc-bluegreendeployment

テストファー
スト

TDDの観点から
TDDでは、なぜテストファーストするのか

「テストファーストしてないテストは怖い」
-@setoazusa

テストを先に書くことはどんな意味があるのか
• テストに求められる機能は、成功するとGreenに
なり、そうでない時にRedになること
• テストファーストしてないテストは、「まず失
敗させる」ことができないため、テストとして
の信頼性がさがる
• 「失敗していないテストのカバレッジは50%し
かない」

思い出してみてください。
自動化されてないテストで、テスト項目書に
「正しく表示されていること」と記載されてい
て、検証に苦労したことはありませんか？

ユニットテストが「テスト」である以上、テス
トの答えとなるものは先に用意されているはず

TDDではなぜテストファーストするのか
あくまでテストのあるべき姿を追求したことで、
結果としてテストを最初に書くことになるイ
メージ。

• 大事なのは、システムをデリバリーするために、
どうステップを踏んでいくか
• テストファーストを導入できるなら、すればよ
い。
• そうでないとしても、ユニットテストより上位
レベルのテストの項目は先に作成するなど、テ
スト同士で補完していけば良い。

ただ、IT技術者として手札は多いほうがよいの
で、スキルとしてテストファーストできるにこ
したことはないです。

きれいなコー
ド

「動作するきれいなコード」
「動作するきれいなコード」。Ron Jeffries の
この簡潔な言葉が、テスト駆動開発（TDD）の
ゴールだ。動作するきれいなコードはあらゆる
意味で価値がある。
Kent Beck(著) 和田卓人(訳) 「テスト駆動開発」

「動作するきれいなコード」
「きれいなコード」とは？

コードとは芸術作品ではない
コードとはあくまでサービスとして提供するう
えでの設計図
文芸的作品のような美しさ、きれいさよりも解
こうとしているドメインを率直に表現している
かのほうが重要ではないのか

あやうい前提
「実は、『コードのよさは重要だ』という、か
なりあやうい前提に基づいて、この本は書かれ
ている。」
－「実装パターン」から
Kent Beck (著)永田渉長瀬嘉秀(監訳) 「実装パターン」

「無能か有能かの判断な
んて、結局物事を成功さ
せたかどうかでしかない。
勝てば官軍、負ければ賊
軍。無能さを言い訳に努
力しない者は結局何事も
成し遂げず終わる。」
夏海公司「なれる！SE4 誰でも出来る？プロジェクト管理」

だがしかし
• テストしてないけど多分動く
• とりあえずデプロイしてみよう
• なにかわからないけど動いた

「きれいでないコード」が生み出すもの
• 成果物として対価を頂いていることに疑問を
抱くような乱れたコードベース
• 野戦病院のように開発メンバーの入れ替わり
がある疲弊しきった現場
• 天に祈るような気持ちになる爆弾処理のよう
なリリース

ではどうするか
「きれいなコード」ではなく、「きれいでない
コード」がなにか、というのははっきりしてい
る

By Wikinaut (Own work (own photo)) [GFDL (http://www.gnu.org/copyleft/fdl.html) or CC BY-SA 3.0
(http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons
https://ja.wikipedia.org/wiki/スパゲッティプログラム

Robert.C.Martin(Uncle Bob)
「プログラマが知るべき97のこと」から

「よい」コード
「これまで、粗悪なコードに苦しめられてきた
のですから、よいコードが重要であることに間
違いはないのです」
Robert C. Martin (著) 花井志生 (訳) 「Clean Code アジャイルソフトウェア達人の技」

「きれいなコード」とは
今のコードがどのような状況があるか、その
コードが周囲にどのような影響を及ぼしている
か
そこからボトムアップに改善を積み重ねていっ
た先に、「きれいなコード」がある

どうテストす
るか

「不安をテストで表現する」
http://gihyo.jp/dev/serial/01/tdd/0010

@t_wada曰く

私たちプログラマの手を止めるものは何でしょうか。私は
「不安」だと思っています。「もしかしたら」という感情で
すね。「もしかしたら，自分の書いているコードは間違って
いるかもしれない」「もしかしたら，ライブラリの使い方が
正しくないかもしれない…」。（略）
だから，これから書くコードに対して，if文があるだろうな
とか，ループがあるとか，正規表現使わなきゃいけないなと
か，そういった自分自身に対する不安，これから書くことに
対する不安に対して，テストを書いていきます。
「［動画で解説］和田卓人の“テスト駆動開発”講座第10回テストの最小単位は不安」
http://gihyo.jp/dev/serial/01/tdd/0010

• プログラマーとしての「不安」
• データベース技術者としての「不安」
• インフラ担当としての「不安」

「信頼で結ばれた共同体」
James O. Coplien , Neil B. Harriosn (著), 和智右桂 (翻訳) 「組織パターン」

自動テストによる品質の安定がもたらすもの
• チーム開発は、開発者だけでなく、多数のス
テークホルダーが強調して行うもの
• 安定したプロダクトの品質がチーム内相互の
信頼をもたらす

明日から役立
つお役立ち情
報

https://www.flickr.com/photos/okinawa-soba/2951808529/
レガシーコード

「プログラマが知るべき97のこと」

「不具合にテストを書いて立ち向かう」
不具合にテストを書いて立ち向かう - t-wadaのブログ
http://t-wada.hatenablog.jp/entry/debugging-tests

やはりテストを書いて立ち向かってゆくのです。私
はテスト駆動開発を数年間実践してきた中で、心が
けているひとつの「掟」があります。それは「不具
合の修正時には必ず先に不具合を再現する自動テス
トを書いてから修正する」というものです。これは
もちろん私の発案ではなく、 XP（eXtreme
Programming）や TDD の先達から学び、それを
実践するうちに私にも身についてきたものです。

結構やってたりする

「レガシーコード改善ガイド」

仕様化テスト(characterization test)
「仕様化テストは、コードの実際の振る舞いを
明らかにするテストです。『システムはこれを
するべきだ』とか『こうしていると思う』とい
うことを確認するテストではありません。仕様
化テストは、システムの現在の振る舞いをその
まま文章化します。」

なぜTDDする
のか

TDDはプログラマーの義務？

だがちょっと待って欲しい
「テストを書く／書かない」ということは、道
義的な責任の問題ではない

「テスト」と責任の関係
• テストという工程は、その性格上、品質保証
や、成果物への責任と強い関係をもっている
• 「テストを書くべきだ」という論に明快に異
を唱えられる人は少ない

• 開発プロセスの望ましい姿を論じていたはず
が、道義的な責任の問題になってしまう
• テストを書く人と書かない人の間の感情的な
対立は、何も生み出さない

「TDDやれば偉いわけじゃない」
http://b.hatena.ne.jp/entry/232721484/comment/t-wada

幻想を捨てる
• カバレッジ100%
• ユニットテストを書けばバグがなくなる

「テストを書く」ということは、継続的インテ
グレーション(CI)や静的解析、コードレビュー
やペアプログラミングなど、チーム開発のため
のプラクティスと連携して、初めてその力を発
揮する。

なぜTDDするのか
私の場合…

信頼できる成果物のために
「技術力は信頼関係につながる。作業を正確に
見積もり、最初から品質の高いものを届け、高
速なフィードバックループを構築すれば、あな
たは信頼されるパートナーになれる。」
Kent Beck・Cynthia Andres(著) 角征典(訳) 「エクストリームプログラミング」

「君が質の高いソフトウェアを届けることは誰
にも止められない。君が現場に立って、お客さ
んに向けてプロジェクトの状況と、プロジェク
トに必要なことを誠実に伝えることも誰にも止
められないんだ。」
Jonathan Rasmusson(著) 西村直人・角谷信太郎(監訳)
「アジャイルサムライ達人開発者への道」

ありがとうございました！
• 大中浩行(Onaka,Hiroyuki)
• @setoazusa
• グロースエクスパートナーズ株式会社
アーキテクチャソリューション部
テクニカルリード
• http://blog.fieldnotes.jp/

TDDはじめて物語Second Season(updated)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à TDDはじめて物語Second Season(updated)

Similaire à TDDはじめて物語Second Season(updated) (20)

Plus de Hiroyuki Ohnaka

Plus de Hiroyuki Ohnaka (20)

TDDはじめて物語Second Season(updated)