「TDDはじめて物語」 #tddbc

#ccc_r11

Copyright 2016 Hiroyuki Onaka

TDDはじめて物語

2016/2/27 TDDBC in Tokyo 2016-02

大中浩行

#ccc_r11


テスト駆動開発(Test Driven Development)

TDDとは？

Generated by 社畜ちゃん台詞メーカー

http://blog.oukasoft.com/OS/

http://blog.oukasoft.com/OS/

#ccc_r11


By National Photo Company [Public domain], via Wikimedia Commonshttps://en.wikipedia.org/wiki/Bulletproof_vest

テストファーストしたら？

https://en.wikipedia.org/wiki/Bulletproof_vest

#ccc_r11


？

By NASA [Public domain], via Wikimedia Commons https://en.wikipedia.org/wiki/Self-replicating_machine

テストが自動化されたら？

https://en.wikipedia.org/wiki/Self-replicating_machine

#ccc_r11


TDDとは

「TDDとは、プログラミングとテストすること

を工程として統合した開発スタイルです。」

- @setoazusa

#ccc_r11


アジェンダ

• TDDとは

• テストファーストとは

• なぜTDDするのか

• TDDには何が必要か

• なぜTDDするのか(again)

#ccc_r11


TDDとは

#ccc_r11

Copyright 2016 Hiroyuki Onaka ※絶版

TDDとは

#ccc_r11


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 Commonshttps://en.wikipedia.org/wiki/Kent_Beck

Kent Beck

https://en.wikipedia.org/wiki/Kent_Beck

#ccc_r11


TDDとは

１．素早くテストを追加する。

２．すべてのテストを実行し、新しいテストの失敗を確

認する。

３．小さな修正を行う。

４．すべてのテストを実行し、すべての成功を確認する。

５．重複を取り除くためにリファクタリングを行う。

ケント・ベック(著)長瀬嘉秀(訳)「テスト駆動開発入門」

#ccc_r11


座標平面上にある点で、x座標 (x-coordinate) 、y座標

(y-coordinate) がともに整数である点を格子点と呼び

ます。

• x座標とy座標を与えて格子点を生成してください

• 生成した格子点からx座標とy座標を取得してください

• 生成した格子点から文字列表記 (notation) を取得してく

ださい

#ccc_r11


テストを追加する。

@RunWith(JUnit5.class)public class GridPoinTest {

@Testpublic void x座標とy座標を与えて格子点を生成できること(){

}

@Testpublic void 生成した格子点からx座標とy座標を取得できること(){

}@Test@Disabledpublic void 生成した格子点から文字列表記を取得できること() {}

}

#ccc_r11


テストを追加する。

@RunWith(JUnit5.class)public class GridPoinTest {

@Testpublic void x座標とy座標を与えて格子点を生成できること(){

// コンストラクターのテストは通常書かないですが、// 課題の「格子点を生成できること」と対応を取るためにあえて// テスト化していますGridPoint point = new GridPoint(4, 7);assertNotNull(point);

}

@Testpublic void 生成した格子点からx座標とy座標を取得できること(){

GridPoint point = new GridPoint(4, 7);assertEquals(4, point.getX());

}@Test@Disabledpublic void 生成した格子点から文字列表記を取得できること() {}

}

#ccc_r11


すべてのテストを実行し、新しいテストの失敗を確認する。

#ccc_r11


小さな修正を行う。

public class GridPoint {

private int x;

public GridPoint(int x, int y) {this.x = x;

}

public int getX() {return x;

}}

#ccc_r11


すべてのテストを実行し、すべての成功を確認する。

#ccc_r11


再びテストを追加する。

@Testpublic void x座標とy座標を与えて格子点を生成できること() {

GridPoint point = new GridPoint(4, 7);assertNotNull(point);

@Testpublic void 生成した格子点からx座標とy座標を取得できること() {

GridPoint point = new GridPoint(4, 7);assertAll(

() -> { assertEquals(4, point.getX()); },() -> { assertEquals(7, point.getY()); }

);}

#ccc_r11


再びテストを実行する。

#ccc_r11


修正を行う。

public class GridPoint {

private int x;

private int y;

public GridPoint(int x, int y) {this.x = x;this.y = y;

}public int getX() { return x; }

public int getY() { return y; }}

#ccc_r11


すべてのテストを実行し、すべての成功を確認する。

#ccc_r11


重複を取り除くためにリファクタリングを行う。

private GridPoint point;

@BeforeEachpublic void before(){

point = new GridPoint(4, 7);}@Testpublic void x座標とy座標を与えて格子点を生成できること() {

assertNotNull(point);}@Testpublic void 生成した格子点からx座標とy座標を取得できること() {

assertAll(() -> { assertEquals(4, point.getX()); },() -> { assertEquals(7, point.getY()); }

);}

#ccc_r11


フィードバックループ

「運転というのはね、車を正しい方向に走らせ

ることじゃないの。常に注意を払って、こっち

に行ったら少し戻して、あっちに行ったら少し

戻して、そうやって軌道修正していくものよ」

これがXP のパラダイムだ。注意して、適応して、

変更する。

Kent Beck・Cynthia Andres(著) 角征典(訳) 「エクストリームプログラミング」

#ccc_r11


テストファースト

#ccc_r11


TDDの観点から

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

#ccc_r11


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

-@setoazusa

#ccc_r11


テストを先に書くことはどんな意味があるのか

• テストに求められる機能は、成功するとGreenに

なり、そうでない時にRedになること

• テストファーストしてないテストは、「まず失

敗させる」ことができないため、テストとして

の信頼性がさがる

• 「失敗していないテストのカバレッジは50%し

かない」

#ccc_r11


思い出してみてください。

自動化されてないテストで、テスト項目書に

「正しく表示されていること」と記載されてい

て、検証に苦労したことはありませんか？

#ccc_r11


ユニットテストが「テスト」である以上、テス

トの答えとなるものは先に用意されているはず

#ccc_r11


TDDではなぜテストファーストするのか

あくまでテストのあるべき姿を追求したことで、

結果としてテストを最初に書くことになるイ

メージ。

#ccc_r11


よくある質問

「TDDって、テストを必ず先に書かなければい

けないんですか？」

#ccc_r11


http://www.slideshare.net/YasutoEnjoji/20150621-asbc-pub/29

http://www.slideshare.net/YasutoEnjoji/20150621-asbc-pub/29

#ccc_r11


テストファーストよりも大事なこと

• 「1ヶ月かけてコーディング、1ヶ月かけてテ

スト」のようなアンチパターンから、どれだ

けプログラミングとテストを連携して開発が

できるようにするか

• テストによって開発が駆動されているか

#ccc_r11


• 大事なのは、システムをデリバリーするために、

どうステップを踏んでいくか

• テストファーストを導入できるなら、すればよ

い。

• そうでないとしても、ユニットテストより上位

レベルのテストの項目は先に作成するなど、テ

スト同士で補完していけば良い。

#ccc_r11


ただ、IT技術者として手札は多いほうがよいの

で、スキルとしてテストファーストできるにこ

したことはないです。

#ccc_r11


なぜTDDするのか

#ccc_r11


最初に答えをいいます

「継続的インテグレーションをもたらすための

核心である素早いフィードバックは、ユニット

テストのカバレッジが十分にないと可能になら

ないのだ」

Jez Humble,David Farley(著) 和智右桂(訳)「継続的デリバリー信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化」

#ccc_r11


「エラーが自動的に増殖するのがDevOps」

https://twitter.com/devops_borat/status/41587168870797312

https://twitter.com/devops_borat/status/41587168870797312

#ccc_r11


「テストがないコードはレガシーコードだ！」

#ccc_r11


Test Early and Often

Microsoft 「Test Early and Often」

https://msdn.microsoft.com/library/ee330950.aspx

https://msdn.microsoft.com/library/ee330950.aspx

#ccc_r11


Shift left Testing

By DonFiresmith (Own work) [CC BY-SA 4.0 (http://creativecommons.org/licenses/by-sa/4.0)],via Wikimedia Commonshttps://en.wikipedia.org/wiki/Shift_left_testing

https://en.wikipedia.org/wiki/Shift_left_testing

#ccc_r11


とはいうものの…

• TDD=テスト自動化ではない

#ccc_r11


TDDが目指すもの

「動作するきれいなコード」、ロン・ジェフ

リーズのこの簡潔な言葉は、TDD（テスト駆動

開発）の目標である。動作するきれいなコード

は、あらゆる理由で価値がある。

Kent Beck(著) 長瀬嘉秀(監訳) 「テスト駆動開発入門」

#ccc_r11


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

「きれいなコード」とは？

#ccc_r11


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 Commonshttps://ja.wikipedia.org/wiki/スパゲッティプログラム

きれいでないコード(スパゲッティーコード)

https://ja.wikipedia.org/wiki/スパゲッティプログラム

#ccc_r11


では「きれいなコード」とは

…なんだ？

#ccc_r11


「動作するきれいなコード」を英語で言うと、

「Clean code that works」

#ccc_r11


#ccc_r11


とはいっても、「クリーン」にも色々ありまして

• 複雑度

• メソッド／関数の行数

• コードスタイル

• 命名規則

• etc…

#ccc_r11


「クリーンなコード」についてはこちらを

#ccc_r11


どうテストするか

#ccc_r11


「不安をテストで表現する」

http://gihyo.jp/dev/serial/01/tdd/0010


#ccc_r11


@t_wada曰く

#ccc_r11


私たちプログラマの手を止めるものは何でしょうか。私は

「不安」だと思っています。「もしかしたら」という感情で

すね。「もしかしたら，自分の書いているコードは間違って

いるかもしれない」「もしかしたら，ライブラリの使い方が

正しくないかもしれない…」。（略）

だから，これから書くコードに対して，if文があるだろうな

とか，ループがあるとか，正規表現使わなきゃいけないなと

か，そういった自分自身に対する不安，これから書くことに

対する不安に対して，テストを書いていきます。

「［動画で解説］和田卓人の“テスト駆動開発”講座第10回テストの最小単位は不安」http://gihyo.jp/dev/serial/01/tdd/0010


#ccc_r11


• プログラマーとしての「不安」

• データベース技術者としての「不安」

• インフラ担当としての「不安」

#ccc_r11


• お互いが不安に感じていることを認める。

• その人の弱さを認める。それを品質保証の出

発点にする。

#ccc_r11


「信頼で結ばれた共同体」

James O. Coplien , Neil B. Harriosn (著), 和智右桂 (翻訳) 「組織パターン」

#ccc_r11


もう一つ、よく聞く話

「TDDでテストすれば、他のテストはいらない

んですか？」

#ccc_r11


開発者と品質保証の関係

• 開発者テストのレベルで「開発者の思ったと

おりに動く」ことが保証されているから、品

質保証のテストは品質の検証に注力できる

• 品質保証のテストが後詰めとして控えている

から、開発者テストはプログラムの中の勘所

を押さえることに注力できる

#ccc_r11


製品品質モデル(JIS X 25010)

• 機能適合性

• 性能効率性

• 互換性

• 使用性

• 信頼性

• セキュリティ

• 保守性

• 移植性

JIS X 25010（ISO/IEC 25010）「システム及びソフトウェア製品の品質要求及び評価（SQuaRE）－システム及びソフトウェア品質モデル」

#ccc_r11


アジャイルテストの四象限

Lisa Crispin,Janet Gregory(著) 榊原彰(監訳)「実践アジャイルテスト」

#ccc_r11


「二重のフィードバックループ」

Steve Freeman, Nat Pryce「Growing Object-Oriented Software, Guided by Tests」(邦訳「実践テスト駆動開発」)

#ccc_r11


BDD(Behavior-Driven Development)

John Ferguson Smart「BDD in Action Behavior-Driven Development for the whole software lifecycle」

#ccc_r11


なぜテストするか

#ccc_r11


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

#ccc_r11


だがちょっと待って欲しい

「テストを書く／書かない」ということは、道

義的な責任の問題ではない

#ccc_r11


「テスト」と責任の関係

• テストという工程は、その性格上、品質保証

や、成果物への責任と強い関係をもっている

• 「テストを書くべきだ」という論に明快に異

を唱えられる人は少ない

#ccc_r11


• 開発プロセスの望ましい姿を論じていたはず

が、道義的な責任の問題になってしまう

• テストを書く人と書かない人の間の感情的な

対立は、何も生み出さない

#ccc_r11


「TDDやれば偉いわけじゃない」

http://b.hatena.ne.jp/entry/232721484/comment/t-wada

http://b.hatena.ne.jp/entry/232721484/comment/t-wada

#ccc_r11


幻想を捨てる

• カバレッジ100%

• ユニットテストを書けばバグがなくなる

#ccc_r11


「テストを書く」ということは、継続的インテ

グレーション(CI)や静的解析、コードレビュー

やペアプログラミングなど、チーム開発のため

のプラクティスと連携して、初めてその力を発

揮する。

#ccc_r11


TDDが銀の弾丸でないなら、なぜTDDするのか

その前に、ちょっと世の中の様子を見てみよう

#ccc_r11


https://twitter.com/yotchang4s/status/699030352686256129

https://twitter.com/yotchang4s/status/699030352686256129

#ccc_r11


https://www.google.co.jp/search?q=%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%9A%9C%E5%AE%B3&tbm=nws

https://www.google.co.jp/search?q=%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%9A%9C%E5%AE%B3&tbm=nws

#ccc_r11


https://twitter.com/setoazusa/status/650250873017204736

https://twitter.com/setoazusa/status/650250873017204736

#ccc_r11


#笑ってはいけないSIer

#ccc_r11


我々はなぜここにいるのか

• 生活のため？

• お金のため？

• プロだから？

• 技術者だから？

#ccc_r11


なぜTDDするのか

私の場合…

#ccc_r11


信頼できる成果物のために

「技術力は信頼関係につながる。作業を正確に

見積もり、最初から品質の高いものを届け、高

速なフィードバックループを構築すれば、あな

たは信頼されるパートナーになれる。」

Kent Beck・Cynthia Andres(著) 角征典(訳) 「エクストリームプログラミング」

#ccc_r11


強いチームとは

メンバーを集めた「プロジェクト」を、メン

バーのバックグラウンドを尊重できる「コミュ

ニティ」に出来るか

#ccc_r11


「君が質の高いソフトウェアを届けることは誰

にも止められない。君が現場に立って、お客さ

んに向けてプロジェクトの状況と、プロジェク

トに必要なことを誠実に伝えることも誰にも止

められないんだ。」

Jonathan Rasmusson(著) 西村直人・角谷信太郎(監訳)「アジャイルサムライ達人開発者への道」

#ccc_r11


ありがとうございました！

• 大中浩行(Onaka,Hiroyuki)

• @setoazusa

• グロースエクスパートナーズ株式会社

アーキテクチャソリューション部

テクニカルリード

• http://blog.fieldnotes.jp/