More Related Content Similar to TDDはじめて物語 Second Season #tddbc
Similar to TDDはじめて物語 Second Season #tddbc (20) More from Hiroyuki Ohnaka
More from Hiroyuki Ohnaka (20) TDDはじめて物語 Second Season #tddbc1. Copyright 2017 Hiroyuki Onaka
TDDはじめて物語
Second Season
2017/9/30 TDDBC Tokyo 2017-09
大中浩行
この作品は クリエイティブ・コモンズ 表示 4.0 国際 ライセンスの下に提供されています。
2. Copyright 2017 Hiroyuki Onaka
突然ですが、ここで問題です
平成28年春期 応用情報技術者試験(午前) より
https://www.jitec.ipa.go.jp/1_04hanni_sukiru/mondai_kaitou_2016h28_1/2016h28h_ap_am_qs.pdf
4. Copyright 2017 Hiroyuki Onaka
By National Photo Company [Public domain], via Wikimedia Commons
https://en.wikipedia.org/wiki/Bulletproof_vest
テストファースト
6. Copyright 2017 Hiroyuki Onaka
アジェンダ
• ソフトウェア開発を巡る状況
• TDDとは
• TDDの構成要素
• テストファーストとは
• きれいなコード
• どうテストするか
• 明日から役立つお役立ち情報
• なぜTDDするのか
9. Copyright 2017 Hiroyuki Onaka
「99%の信頼性を持つスマートフォンを使って
いるユーザーには、サービスの信頼性99.99%
の場合と、99.999%の場合との違いは分からな
いのです。」
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy.
澤田 武男、関根 達夫、細川 一茂、矢吹 大輔(監訳) 玉川 竜司(訳)
「SRE サイトリライアビリティエンジニアリング」
10. Copyright 2017 Hiroyuki Onaka
「スライムが強かったらバグ」
「たとえばドラゴンクエストシリーズの序盤で
対戦するモンスターのスライムが、まわりのモ
ンスターより強いようなことがあればドラゴン
クエストシリーズのお客様視点では異常です。
仕様書に書いてあったとしても指摘すべきで
す。」
青山 公士「国民的RPG オンライン化へのチャレンジドラゴンクエストⅩ開発ノウハウ大公開」
(WEB+DB PRESS vol.90)
11. Copyright 2017 Hiroyuki Onaka
• 「品質」というものの捉え方の多様化
• バグのモグラ叩きのなかからは、多様化する
品質への要求に答えることはできない
• システム開発の成果物たるプログラムに対す
る、内部品質への要求の高まり
15. Copyright 2017 Hiroyuki Onaka
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
16. Copyright 2017 Hiroyuki Onaka
TDDとは
TDDのサイクルは、以下の通りである。
• 小さなテストを追加する。
• すべてのテストを実行し失敗する。
• 変更を行う。
• テストを実行し、成功する。
• 重複を取り除くために、リファクタリングを行う。
ケント・ベック(著)長瀬嘉秀(訳)「テスト駆動開発入門」
17. Copyright 2017 Hiroyuki Onaka
例題:FizzBuzz
1から100までの数をプリントするプログラムを
書け。ただし3の倍数のときは数の代わりに
「Fizz」と、5の倍数のときは「Buzz」とプリント
し、3と5両方の倍数の場合には「FizzBuzz」とプ
リントすること。
18. Copyright 2017 Hiroyuki Onaka
テストを追加する。
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));
}
}
20. Copyright 2017 Hiroyuki Onaka
小さな修正を行う。
public class FizzBuzz {
public String fizzBuzz(int num) {
if (num % 3 == 0){
return "Fizz";
}
return Integer.toString(num);
}
}
22. Copyright 2017 Hiroyuki Onaka
フィードバックループ
「運転というのはね、車を正しい方向に走らせ
ることじゃないの。常に注意を払って、こっち
に行ったら少し戻して、あっちに行ったら少し
戻して、そうやって軌道修正していくものよ」
これがXP のパラダイムだ。注意して、適応して、
変更する。
Kent Beck・Cynthia Andres(著) 角征典(訳) 「エクストリームプログラミング」
25. Copyright 2017 Hiroyuki Onaka
xUnitによる自動テスト
• 関数やメソッドごとに、エントリーポイント
(C言語ならmain関数)をもうけてデバッグす
るという、熟練したプログラマーのプラク
ティスをフレームワーク化したもの
26. Copyright 2017 Hiroyuki Onaka
xUnit
• テストに求められる要素を、フレームワーク
化したもの。Smalltalkのテスティングフ
レームワークSUnitがはじまり
• JavaのJUnitを始めとして、各言語・各環境
に移植されたものの総称
Kent Beck 「With Patterns」(archive)
https://web.archive.org/web/20150315073817/http://www.xprogramming.com/testfram.htm
28. Copyright 2017 Hiroyuki Onaka
Fixture/テストケース/チェック/テストスイート
(1)
• Fixture
テストを実行するにあたって準備するものの
総称
• テストケース
テストそのものを「オブジェクト」として表
現したもの(JUnitだとメソッド)
29. Copyright 2017 Hiroyuki Onaka
Fixture/テストケース/チェック/テストスイート
(2)
• チェック
アサーションとして実装される
self-validating(自己検証可能)であること
• テストスイート
テストケースを集約して実行する。
31. Copyright 2017 Hiroyuki Onaka
仮実装・三角測量・明白な実装
• 仮実装
アサーションを書いた後、アサーションを通
すための必要最小限の実装を行う。
• テストの正当性を検証するため(テストのテスト)
• テストから最短距離でフィードバックを得るため
32. Copyright 2017 Hiroyuki Onaka
仮実装・三角測量・明白な実装
• 三角測量
仮実装から本実装を引き出す際に、二つのテス
トケースを重ね合わせて実装を導き出す
• 明白な実装
テストケースから本実装を明確にイメージでき
るときに、テストケースを安全網にして、直接
実装する
35. Copyright 2017 Hiroyuki Onaka
Yu Asano「私のTDDのこころ」より
https://www.slideshare.net/uasano/agile-samuraibasecamp-tdd-keynote/43
36. Copyright 2017 Hiroyuki Onaka
リファクタリング
• 「コードのあるべき姿」はプログラマーがキー
ボードを叩く中であらわれる。アーキテクトが
事前にコードの理想像を示すことはできない
• 一度プログラミングしたら、そこで完成なわけ
でもない
• 「動くコードに触るな」に抗う
37. Copyright 2017 Hiroyuki Onaka
• 継続的にリファクタリングを続けられる、
「動くコードに手を入れられる」のが強い
チーム
• テストを安全網にすることで、リファクタリ
ングを含めて思い切って手を打つことが出来
るようになる。
38. Copyright 2017 Hiroyuki Onaka
テストを安全網にした事例
https://www.slideshare.net/setoazusa/move-to-java8
https://www.slideshare.net/setoazusa/jjug-ccc-bluegreendeployment
42. Copyright 2017 Hiroyuki Onaka
テストを先に書くことはどんな意味があるのか
• テストに求められる機能は、成功するとGreenに
なり、そうでない時にRedになること
• テストファーストしてないテストは、「まず失
敗させる」ことができないため、テストとして
の信頼性がさがる
• 「失敗していないテストのカバレッジは50%し
かない」
46. Copyright 2017 Hiroyuki Onaka
• 大事なのは、システムをデリバリーするために、
どうステップを踏んでいくか
• テストファーストを導入できるなら、すればよ
い。
• そうでないとしても、ユニットテストより上位
レベルのテストの項目は先に作成するなど、テ
スト同士で補完していけば良い。
49. Copyright 2017 Hiroyuki Onaka
「動作するきれいなコード」
「動作するきれいなコード」、ロン・ジェフ
リーズのこの簡潔な言葉は、TDD(テスト駆動
開発)の目標である。動作するきれいなコード
は、あらゆる理由で価値がある。
Kent Beck(著) 長瀬 嘉秀(監訳) 「テスト駆動開発入門」
51. Copyright 2017 Hiroyuki Onaka
コードとは芸術作品ではない
コードとはあくまでサービスとして提供するう
えでの設計図
文芸的作品のような美しさ、きれいさよりも解
こうとしているドメインを率直に表現している
かのほうが重要ではないのか
52. Copyright 2017 Hiroyuki Onaka
あやうい前提
「実は、『コードのよさは重要だ』という、か
なりあやうい前提に基づいて、この本は書かれ
ている。」
-「実装パターン」から
Kent Beck (著)永田 渉 長瀬 嘉秀(監訳) 「実装パターン」
53. Copyright 2017 Hiroyuki Onaka
「無能か有能かの判断な
んて、結局物事を成功さ
せたかどうかでしかない。
勝てば官軍、負ければ賊
軍。無能さを言い訳に努
力しない者は結局何事も
成し遂げず終わる。」
夏海公司「なれる!SE4 誰でも出来る?プロジェクト管理」
55. Copyright 2017 Hiroyuki Onaka
「きれいでないコード」が生み出すもの
• 成果物として対価を頂いていることに疑問を
抱くような乱れたコードベース
• 野戦病院のように開発メンバーの入れ替わり
がある疲弊しきった現場
• 天に祈るような気持ちになる爆弾処理のよう
なリリース
57. Copyright 2017 Hiroyuki Onaka
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/スパゲッティプログラム
59. Copyright 2017 Hiroyuki Onaka
「よい」コード
「これまで、粗悪なコードに苦しめられてきた
のですから、よいコードが重要であることに間
違いはないのです」
Robert C. Martin (著) 花井 志生 (訳) 「Clean Code アジャイルソフトウェア達人の技」
60. Copyright 2017 Hiroyuki Onaka
「きれいなコード」とは
今のコードがどのような状況があるか、その
コードが周囲にどのような影響を及ぼしている
か
そこからボトムアップに改善を積み重ねていっ
た先に、「きれいなコード」がある
64. Copyright 2017 Hiroyuki Onaka
私たちプログラマの手を止めるものは何でしょうか。私は
「不安」だと思っています。「もしかしたら」という感情で
すね。「もしかしたら,自分の書いているコードは間違って
いるかもしれない」「もしかしたら,ライブラリの使い方が
正しくないかもしれない…」。(略)
だから,これから書くコードに対して,if文があるだろうな
とか,ループがあるとか,正規表現使わなきゃいけないなと
か,そういった自分自身に対する不安,これから書くことに
対する不安に対して,テストを書いていきます。
「[動画で解説]和田卓人の“テスト駆動開発”講座 第10回 テストの最小単位は不安」
http://gihyo.jp/dev/serial/01/tdd/0010
67. Copyright 2017 Hiroyuki Onaka
自動テストによる品質の安定がもたらすもの
• チーム開発は、開発者だけでなく、多数のス
テークホルダーが強調して行うもの
• 安定したプロダクトの品質がチーム内相互の
信頼をもたらす
71. Copyright 2017 Hiroyuki Onaka
「不具合にテストを書いて立ち向かう」
不具合にテストを書いて立ち向かう - t-wadaのブログ
http://t-wada.hatenablog.jp/entry/debugging-tests
72. Copyright 2017 Hiroyuki Onaka
やはりテストを書いて立ち向かってゆくのです。私
はテスト駆動開発を数年間実践してきた中で、心が
けているひとつの「掟」があります。それは「不具
合の修正時には必ず先に不具合を再現する自動テス
トを書いてから修正する」というものです。これは
もちろん私の発案ではなく、 XP(eXtreme
Programming) や TDD の先達から学び、それを
実践するうちに私にも身についてきたものです。
75. Copyright 2017 Hiroyuki Onaka
仕様化テスト(characterization test)
「仕様化テストは、コードの実際の振る舞いを
明らかにするテストです。『システムはこれを
するべきだ』とか『こうしていると思う』とい
うことを確認するテストではありません。仕様
化テストは、システムの現在の振る舞いをその
まま文章化します。」
79. Copyright 2017 Hiroyuki Onaka
「テスト」と責任の関係
• テストという工程は、その性格上、品質保証
や、成果物への責任と強い関係をもっている
• 「テストを書くべきだ」という論に明快に異
を唱えられる人は少ない
83. Copyright 2017 Hiroyuki Onaka
「テストを書く」ということは、継続的インテ
グレーション(CI)や静的解析、コードレビュー
やペアプログラミングなど、チーム開発のため
のプラクティスと連携して、初めてその力を発
揮する。
85. Copyright 2017 Hiroyuki Onaka
信頼できる成果物のために
「技術力は信頼関係につながる。作業を正確に
見積もり、最初から品質の高いものを届け、高
速なフィードバックループを構築すれば、あな
たは信頼されるパートナーになれる。」
Kent Beck・Cynthia Andres(著) 角征典(訳) 「エクストリームプログラミング」
86. Copyright 2017 Hiroyuki Onaka
「君が質の高いソフトウェアを届けることは誰
にも止められない。君が現場に立って、お客さ
んに向けてプロジェクトの状況と、プロジェク
トに必要なことを誠実に伝えることも誰にも止
められないんだ。」
Jonathan Rasmusson(著) 西村直人・角谷信太郎(監訳)
「アジャイルサムライ 達人開発者への道」
87. Copyright 2017 Hiroyuki Onaka
ありがとうございました!
• 大中浩行(Onaka,Hiroyuki)
• @setoazusa
• グロースエクスパートナーズ株式会社
アーキテクチャソリューション部
テクニカルリード
• http://blog.fieldnotes.jp/