n416の日記

現代ソフトウェアの技術要素

バージョン管理
テスティング
自動化

この３つを開発者は身につけるべきで、必須のスキルである。
バージョン管理がまずは大事。これがないとお話にならない。
できるだけ分散バージョン管理の方がいい
SCMBCがあるので参加してみるとかも良い
次にテスティングこれは今回の話のスコープなんで、ここではあまり語らない
最後に自動化
ジェンキンスでもいいし、cronで回ってるシェルでもいい。
# Stagehand_TestRunnerとかいいかなと思う。
https://wiki.jenkins-ci.org/display/JA/Meet+Jenkins
http://iteman.jp/blog/2009/10/php---stagehand-testrunner.html
とにかく、なんでもいい。
人間は人間にしか出来ない事をするように。単純作業は機械にやらせましょう。

この３つの技術要素は３種の神器ではない
３種の仁義は例えば
鎧
兜
剣
みたいな感じで、割と剣だけでなんとかなるなんてこともある。

この３つの技術要素は３脚椅子であり、一個でもないと転倒してしまうと心得よう

TDDを語る前に
テストって言葉には混乱がある。
テストという言葉がさすものがバラバラ単体テストユニットいろいろあるよね？
組織や文化によってそのマッピングが異なってくる。
テストの範囲によって、分量、粒度は曖昧さ、が生じてしまう。
限界がある。

「誰が何のためにテストを行うのか」という観点で考えると以下のようにまとめることができる。

Debelopper Testing 開発者の開発促進のためのテスト
CustomerTesting 顧客の進捗管理のためのテスト
QATesting 品質保証の担当者の品質保証のためのテスト

プログラマの
プログラマによる
プログラマのためのテスト。
それがDebelopperTest。

TDDとはなにか
動作するきれいなコードへの道は
「きれいな設計によってしか、動作するきれいなシステムはできない！」
と教育では教えているかもしれないが実際はそんな事ない。
まず動作させてから、美しくして行くシステムもある。
オブジェクト指向の完璧さの呪いにハマってはならない

動作するソースをきれいにしてゆくと良い事は
動かしてみて初めて分かる事が多いから。

いくら要件時に完璧な設計だと思っても、作ってゆくうちに、それが最善ではない事が判明する事が多い。

TDDのサイクルとは

テストを書き
そのテストを実行して失敗させ
目的のコードを書き
１で書いたテストを成功させ
テストがとおるまでリファクタリングを行う
１−５を繰り返すサイクルの事をいう

尚、リファクタリングだけが、ソースをきれいに持って行けるのだから、手を抜いてはならない。

TDDのこころ
１つずつ、少しずつ行う。
日々相手にするのは大きな相手である。少しずつ倒そう。
１日かけて通らないようなテストをするのは大変だ。
大きな問題を小さな問題に分割するというプログラミングの基本中の基本がテストでもやはり重要

ひとりずつ仕留める
宮本武蔵は五輪書に書いていて、1対１であれば負けない方法を説いている
逆説的に言えば１対多では負ける！のである。

素早くまわす
回転のスピードのリズムについては早ければ早いだけ良い。
１時間、１時間、５時間ではTDDとは言えない。
５分で書いて４分で書いてというのがTDD

自分が最初のユーザーである
テストから先に書くということは、自分が一番始めのユーザーとなる。
自分が使いにくいな…と思うようなコードを人に見せてはいけない
自分が最初に使う事によって問題が明らかになる
中の人目線ではなく、お客さん目線を得る事が出来る
Google的には「ドッグフードを食べる」と言う

道具にこだわる
速度をあげて行くために必要
エディタにこだわる。

不安をテストにする
自分が不安に思っている事をテストにする。
GetterやSetterに対してテストを書くのはおかしいっちゃおかしい。
そんな所に不安をもつことは無いから。
だからムラを推奨する。
自分の不安の量と人の不安の量は違う。
祈るのでは駄目
テストが１行も書かれていないというのは不安
リリースを早く回すとしても、システムすべてを把握するのは難しいから

テストは命綱
緊急リリースなので…となった時、テストが出来ていないと不安で仕方がない。
テストは確信を育てるための物である
さぁ飛び込め！といわれてからテストを書くのでは遅すぎる

なぜTDDやっているのか？
私たちは完璧なプログラマではない
最初から思い通りのコードがかけるほど私たちは賢くない
最初から思い通りに動作するほど対象は単純ではない

素早く対象に近づきき、フィードバックを得手から方向修正をおこないながら進んでゆける。
TDDは目的ではなく手段
即座にフィードバックを得るため
書いたコードに自信を持つため
これから各コードに自信を持つため
即座に知る事が出来る事は大切である。

真の目的は健康（怪しいけどきにしない）
コードの健康
自分の書くコードに対応できるかどうか
無駄の無い体になっているかどうか
リファクタリングが必要
リファクタリングをするためにはテストが必要
チームの健康
健康な人間は、様々な所を把握できる人
不安の克服
勝ち続ける事で成功体験を積む
これがTDDの目的

事例から分かること
http://blogs.itmedia.co.jp/morisaki/2010/02/tdd-ebd9.html
実装時間は２割増える。バグは半分以下になる。

半分の技術者は開発工数を減らすと感じるらしい。
２割実装が増えてるのになぜか？
デバッグの工数が激減するので、結果的に工数としては短くなったように感じる。
デバグは推論の時間。だから時間が読めない。
TDDで実施すると予想外の挙動が出たときにバグへの突き止めが楽になる。

デバッガはデバグをするための道具ではなく、リーディングの道具に使おう！

応用
テストの無いコードが既にたくさんある
＞レガシーコード改善ガイドを読む

レガシーコード改善ガイド (Object Oriented SELECTION)

作者: マイケル・C・フェザーズ,ウルシステムズ株式会社,平澤章,越智典子,稲葉信之,田村友彦,小堀真義
出版社/メーカー: 翔泳社
発売日: 2009/07/14
メディア: 大型本
購入: 45人クリック: 673回
この商品を含むブログ (157件) を見る

既にデータの入ったデーターベースがある
＞データーベースリファクタリングを読む

データベース・リファクタリング

作者: スコット W アンブラー,ピラモド・サダラージ,梅澤真史,越智典子,小黒直樹
出版社/メーカー: ピアソンエデュケーション
発売日: 2008/03/26
メディア: 単行本
購入: 10人クリック: 211回
この商品を含むブログ (53件) を見る

テストが脆い
ちょっと変更するとテストがぼこぼこ落ちる
テストが遅い
DB接続とかやっちゃう
＞XUNIT TEST PATTERNS

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

作者: Gerard Meszaros
出版社/メーカー: Addison-Wesley Professional
発売日: 2007/05/21
メディア: ハードカバー
購入: 5人クリック: 210回
この商品を含むブログ (66件) を見る

＞WEB+DB PRESS Vol.63号

WEB+DB PRESS Vol.63

作者: 竹迫良範,和田卓人,おにたま,中島聡,角田直行,はまちや2,上谷隆宏,青木俊介,大塚知洋,生尾剛士,大和田純,永安悟史,馬場俊彰,久保達彦,白土慧,じゅんいち☆かとう,太田昌吾,小野修司,ミック,嶋田裕二,個々一番,みやけん,清水亮,WEB+DB PRESS編集部
出版社/メーカー: 技術評論社
発売日: 2011/06/24
メディア: 大型本
購入: 20人クリック: 434回
この商品を含むブログ (22件) を見る

モダンTDD
Growing Object-Oriented Software, Guided by Tests を読むのも良い
http://www.amazon.co.jp/dp/0321503627/

Growing Object-Oriented Software, Guided by Tests (Addison-Wesley Signature Series (Beck))

作者: Steve Freeman,Nat Pryce
出版社/メーカー: Addison-Wesley Professional
発売日: 2009/10/12
メディア: ペーパーバック
購入: 3人クリック: 76回
この商品を含むブログ (32件) を見る

acts_as_professional!

グリーンバンドをつける。それをみて、テストを書かねばならない事を思い出す。

- - - - -

ということでグリーンバンドを私も６つ注文してみました。（社内に布教して、写経した人にあげる予定！
写経スルホンはコレ。
http://www.amazon.co.jp/dp/4894717115

テスト駆動開発入門

作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
出版社/メーカー: ピアソンエデュケーション
発売日: 2003/09
メディア: 単行本
購入: 45人クリック: 1,058回
この商品を含むブログ (162件) を見る

TDDの写経が終わり次第、付ける予定です。
グリーンバンドの注文はhttps://spreadsheets1.google.com/spreadsheet/viewform?formkey=dFlZU0xBMG5GR0g0cjhnM0ZzRmJGRkE6MQから！

- - - - -

最後のQA

※TDDを組織やチームに導入して、失敗した経験を教えてくださいハードランディングは危険だしトップダウンで実施するのはブレイクスルーのばらつきを生む

※時間的な制約及びコスト面での制約がない場合で、絶対にTDDしなくて良い場面はありますか？
プロトタイピングの最中は基本テストがいらない。
これで行ける！って思ったときにテストを実装してゆく。

速度は落ちるので、寿命がそもそも存在しないようなプログラミングであれば必要なし。１ヶ月の短期的なコンテンツとかも。

※TDDを実践していくにあたり、理解しておいた方が好ましい知識・技術はどのような物があげられますか？
自動化についての考察が必要
オブジェクト指向プログラミングの知識や技術はあるにこした事が無い。
デザインパターンやリファクタリングについての設計技法は知っておくと良い
テスト技法
テストの設計技法
TDDならではの名称
例えば:パラメータライズとかいう言葉は特徴的。知っていればググりやすくなるからいいよね

※非web系のUIのテスト（マウスクリックやキー入力）にいつも困る。どう解決するのがスマートなのか？
人間でしかテストできないものは、人間が行えるようにする。要するにロジック部分を徹底的に自動化する

※TDDを社内で布教するに辺り自分1人しかTDDできる人がいない場合どうやって布教すればいいでしょうか？講演だと実際に身につかないし、ペアプロだと一度に多くは見られないので1人だけだと厳しいです
@HIROCASTさんがやっていることは
やり始めればやれる人を探して、やってもらう。
ここのテストだけ書きましょう！みたいな形。例えば課金ベースの所とか。
テストをしないと不安だと思わせる

※TDDを社内で布教するに辺り自分1人しかTDDできる人がいない場合どうやって布教すればいいでしょうか？講演だと実際に身につかないし、ペアプロだと一度に多くは見られないので1人だけだと厳しいです
テスト手法の底上げを行ってからTDDってのが良い。
例えばxUnitにいきなり行かずにSeleniumをやってもらう。わりと受けが良い。

※テスト駆動開発をどこまでストイックに実践しているか教えてください。（逆に、どんなときにテスト駆動開発のルールを破りますか？）
先行者メリットがあるとき（スタートアップをやらなくちゃいけない時）は、チームで一気にやる。
得体のしれない技術が必要な案件、学習時はテスト開発ではなかったりもする。
でも、やらない場合の博打要素のが多い。基本やった方がいい。

※テストコードのリファクタリング必要？
必要。積極的にすべき。そして、いつもやっておくべき。これが一番低コスト。
テストコードのカバレッジ率を調べてみるとか。