2015/10/14 jjugナイトセミナー「テスト駆動開発ここが聞きたい」

#ccc_r11

テスト駆動開発ここが聞きたい

2015/10/14

大中浩行

#ccc_r11

Copyright 2015 Hiroyuki Ohnaka

• 大中浩行(Ohnaka,Hiroyuki)

• TDD Base Camp

• グロースエクスパートナーズ(株)

• Twitter @setoazusa

• いきものがかり / miwa / ケラケラ

• Javaプログラマー兼インフラエンジニア

#ccc_r11


どうしてこうなった

「ワタシハTDDチョットデキル」

→「CIの構築お願いできますか」

→「デプロイの自動化したいんです」

→「インフラの自動化もお願いしたく」

→（イマココ)

#ccc_r11


アジェンダ

• 「きれいなコード」

• テストファースト

• テストと不安

• テストのジレンマ

• まとめ

#ccc_r11


「きれいなコード」

#ccc_r11

Copyright 2015 Hiroyuki Ohnaka※絶版

#ccc_r11


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

Kent Beck

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

#ccc_r11


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

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

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

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

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

ー「テスト駆動開発入門」から

#ccc_r11


「きれいなコード」

…て、なんだ？

#ccc_r11


#ccc_r11


あやうい前提

「実は、『コードのよさは重要だ』という、か

なりあやうい前提に基づいて、この本は書かれ

ている。」

－「実装パターン」から

#ccc_r11


「無能か有能かの判断な

んて、結局物事を成功さ

せたかどうかでしかない。

勝てば官軍、負ければ賊

軍。無能さを言い訳に努

力しない者は結局何事も

成し遂げず終わる。」

夏海公司「なれる！SE4 誰でも出来る？プロジェクト管理」

#ccc_r11


「テストしてないけど多分動く」

「とりあえずデプロイしてみよう」

「なんかわからないけど動いた」

etc…

#ccc_r11


…で、その結果

#ccc_r11


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

スパゲッティーコード

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

#ccc_r11


https://www.flickr.com/photos/22719239@N04/2246462044/

疲弊しきった現場

https://www.flickr.com/photos/22719239@N04/2246462044/

#ccc_r11


https://ja.wikipedia.org/wiki/対爆スーツ

爆弾処理のようなリリース

https://ja.wikipedia.org/wiki/対爆スーツ

#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&ie=utf-8&oe=utf-8&hl=ja#q=%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%9A%9C%E5%AE%B3&hl=ja&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&ie=utf-8&oe=utf-8&hl=ja#q=%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%9A%9C%E5%AE%B3&hl=ja&tbm=nws

#ccc_r11


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

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

#ccc_r11


「動作するきれいなコード」というのは原文で

言うと「Clean code that works」

#ccc_r11


#ccc_r11


Robert.C.Martin(Uncle Bob)

Kevlin Henney(編)和田卓人(監修)夏目大(訳)「プログラマが知るべき97のこと」から

#ccc_r11


「よい」コード

「これまで、粗悪なコードに苦しめられてきた

のですから、よいコードが重要であることに間

違いはないのです」

#ccc_r11


TDDは「今がどうなっているか」というところ

から始まる、ボトムアップの理論。トップダウ

ンで「TDDの定義」みたいなところから議論を

はじめても、答えにたどり着けない

#ccc_r11


「大抵の管理者は、真実を求めます。仮に彼らが、そう振る

舞っているように見えなくてもです。大抵の管理者は、よい

コードを求めます。仮にスケジュールに悩んでいたとしても

です。彼らはスケジュールと要件を守ることに必死かもしれ

ませんが、それは彼らの仕事なのですから仕方がありません。

あなたがそれに負けない熱意を持ってコードを

守ればよいのです。」

#ccc_r11


結局のところ

重要なのは、コードがきれいなことそのものよ

りも、コードのどういう側面に価値を置くかと

言うこと。

それが積み上がった結果としてのTDD。

#ccc_r11


「きれいなコード」を語る上で、コードが

「リーダブル」であることは重要ですが、今日

の話ではその事に触れていません。

#ccc_r11


#ccc_r11


テストファースト

#ccc_r11


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

テストファースト

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

#ccc_r11


#ccc_r11


「いつテストを作成すべきか。→テスト対象の

コードを作成する前である。」

#ccc_r11


#ccc_r11


「コードを変更する前に、失敗する自動テスト

を書くこと。」

#ccc_r11


再び「クリーンコード」

#ccc_r11


「TDD三原則」

• 失敗する単体テストのコードを書く前に、製品

のコードを書いてはいけない

• コンパイルが通り、適切に失敗する単体テスト

が通るまでは、次の単体テストを書いてはなら

ない

• 現在失敗する単体テストが通るまで、次の製品

コードを書いてはならない

Robert C. Martin(著)花井志生(訳) Clean Code アジャイルソフトウェア達人の技

#ccc_r11


まあこわい

#ccc_r11


こわくないよ！

• テストファーストにはどのような意味がある

のか

#ccc_r11


テストファーストにはどのような意味があるのか

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

※個人の見解です

#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


テストと不安

#ccc_r11


テスト駆動開発は、プログラム中の不安を管理

する方法である。ここで言う不安とは悪い意味

ではない。...（略）...道理にかなった不安、す

なわち「これは困難な問題だから最初から最後

までは分からない」という感覚である。

ー「テスト駆動開発入門」から

#ccc_r11


「不安をテストにする」

http://blog.fieldnotes.jp/entry/2013/12/02/213516

http://blog.fieldnotes.jp/entry/2013/12/02/213516

#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. Copelin Neli B.Harrison(著) 和智右桂(訳)「組織パターン」

#ccc_r11


なので、こういうことではないです！

#ccc_r11


「どんなチームであっても、スムーズに作業す

ることが欠かせない。たとえば、ソフトウェア

開発者は定期的に声を掛けあい、インター

フェースを調整しあい、ビルドを行い、テスト

をしなければならない。」

「組織パターン」から（強調部発表者）

#ccc_r11


まとめると

• メンバー一人一人が不安に感じていることを、

テストの出発点にする

• 各々が弱みに感じている部分をオープンに出

来るようにするチームをつくる

ということです。

#ccc_r11


テストのジレンマ

#ccc_r11


テストのジレンマ

• テストはバグをなおさない

• 品質を改善する手立てを持たない品質保証部

門

• 開発のロールに過度に押しつけられる品質へ

の責任

#ccc_r11


その結果としての「テスト」へのネガティブなイメージ

http://realtime.search.yahoo.co.jp/search?fr=top_ga1_sa&ei=utf-8&p=%E5%8D%98%E4%BD%93%E3%83%86%E3%82%B9%E3%83%88

http://realtime.search.yahoo.co.jp/search?fr=top_ga1_sa&ei=utf-8&p=%E5%8D%98%E4%BD%93%E3%83%86%E3%82%B9%E3%83%88

#ccc_r11


Developer Testingとは

• 開発者がテストに対して抱いたネガティブな

イメージから脱却し、開発者が行うテストを

「開発者の意図を確認する」工程として再定

義する

• その基準は「不安」

#ccc_r11


開発者と品質保証の相互信頼の再構築

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

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

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

• 品質保証や受入のテストが後詰めとして控え

ているから、開発者テストはプログラムの中

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

#ccc_r11


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

Steve Freeman ,Nat Pryce "Growing Object-Oriented Software, Guided by Tests"

#ccc_r11


詳しくはこちらを

#ccc_r11


まとめ

#ccc_r11


TDDをすすめる時に気をつけること

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

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

#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


では、なぜTDDするのか

#ccc_r11


鏡の国のアリス

#ccc_r11


「その場に居続けるには全力で走り続けなければならない」

「グズな国じゃの！ここではだね、同じ場所に

とどまるだけで、もう必死で走らなきゃいけな

いんだよ。そしてどっかよそに行くつもりなら、

せめてその倍の速さで走らないとね！」

Lewis Carroll(著) 山形浩生(訳) 「鏡の国のアリス」

http://www.genpaku.org/alice02/alice02j.html

http://www.genpaku.org/alice02/alice02j.html

#ccc_r11


http://mizchi.hatenablog.com/entry/2015/10/02/202112

「さよならCofeeScript」

http://mizchi.hatenablog.com/entry/2015/10/02/202112

#ccc_r11


http://d.hatena.ne.jp/higayasuo/20150928/1443415547

http://d.hatena.ne.jp/higayasuo/20150928/1443415547

#ccc_r11


ソフトウェアが死ぬとき

ソフトウェアがドメインの変化に

追従するのをやめたとき

もしくは、

追従できなくなったとき

#ccc_r11


タユムコトナキナガレノナカデ

• コードを生かし続ける

• ビジネスドメインの変化

• 実行環境のバージョンアップ

• 技術トレンドの変化

#ccc_r11


• 「世界を変える」というのは、もっとポジ

ティブなこと

• 自分が変わらずに世界は変わらない

#ccc_r11


私の話

• 新卒文系プログラマー

• 「オブジェクト指向分からない！

Serializableってどういう意味！」

• システムテストでコンパイルエラー！

#ccc_r11


Eclipseというものを知る

→「素晴らしい！書いたコードがコンパイルを

通る！」

#ccc_r11


JUnitというものを知る

→「素晴らしい！書いたコードがちゃんと動

く！」

#ccc_r11


レガシーコード、@t_wadaさん、java-jahttp://d.hatena.ne.jp/t-wada/comment?date=20080224#c

http://d.hatena.ne.jp/t-wada/comment?date=20080224#c

#ccc_r11


これでおしまい！

TDDを習得するのも大事なんですが、「自分が

エンジニアする理由」をもっと大事にしてほし

いと思います。

またお会いしましょう。ご静聴ありがとうござ

いました。