「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/

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

#ccc_r11
？
By NASA [Public domain], via Wikimedia Commons
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 Commons
https://en.wikipedia.org/wiki/Kent_Beck
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 {
@Test
public void x座標とy座標を与えて格子点を生成できること(){
}
@Test
public void 生成した格子点からx座標とy座標を取得できること(){
}
@Test@Disabled
public void 生成した格子点から文字列表記を取得できること() {}
}

#ccc_r11
テストを追加する。
@RunWith(JUnit5.class)
public class GridPoinTest {
@Test
public void x座標とy座標を与えて格子点を生成できること(){
// コンストラクターのテストは通常書かないですが、
// 課題の「格子点を生成できること」と対応を取るためにあえて
// テスト化しています
GridPoint point = new GridPoint(4, 7);
assertNotNull(point);
}
@Test
public void 生成した格子点からx座標とy座標を取得できること(){
assertEquals(4, point.getX());
}
@Test@Disabled
public 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
再びテストを追加する。
@Test
public void x座標とy座標を与えて格子点を生成できること() {
@Test
public void 生成した格子点からx座標とy座標を取得できること() {
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
重複を取り除くためにリファクタリングを行う。
private GridPoint point;
@BeforeEach
public void before(){
point = new GridPoint(4, 7);
}
@Test
public void x座標とy座標を与えて格子点を生成できること() {
}
@Test
public 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

#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

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

#ccc_r11
Test Early and Often
Microsoft 「Test Early and Often」
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 Commons
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 Commons
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

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

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

#ccc_r11
TDDが銀の弾丸でないなら、なぜTDDするのか
その前に、ちょっと世の中の様子を見てみよう

#ccc_r11
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=n
ws

#ccc_r11
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/

「TDDはじめて物語」 #tddbc

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à 「TDDはじめて物語」 #tddbc

Similaire à 「TDDはじめて物語」 #tddbc (20)

Plus de Hiroyuki Ohnaka

Plus de Hiroyuki Ohnaka (19)

「TDDはじめて物語」 #tddbc