テスティング
-
- 安心の土台
- 自分が書いたコードをすぐに試す
自動化
-
- 合理化
- 浮いた時間をコミュニケーション、設計に
- genkins
- 自動化を一歩進める → マシンからの通知 おかしい時だけ知らせる
上の3つを三脚椅子に例える。 → 3つ揃わないと確実に倒れる。
テストという言葉の定義
-
- 言葉の示すものがバラバラ
- 会社ごと、組織ごとに意味するところが違う。
-
- 粒度とか範囲、フェーズで捉えると限界がある。
-
- テストの再分類
- 誰が何のためにテストを行うのか
- 開発者
- 開発促進
- 自信をもって開発するために
- 顧客(プロダクトオーナー)
- 進捗管理
- 受け入れテスト
- 品質担当
- 品質保証
- パフォーマンスやセキュリティ等
- QAテスト
- テストの再分類
TDDとは
-
- ケント・ベックのTDD開発入門。バイブル。
-
- 目的
- 動作する、きれいなコード
- 4象限
- ソフトウェア工学から見て、このゴールに到達するには、
- 到達するには、動作させてから綺麗にするか、綺麗に書いてから動くようにするか。
- 目的
-
- 昔は完璧な設計があると思っていた。それが無いとコードを書いてはいけないという意識があった。
- しかし、実際にコードを書いたらそうじゃなかった。
- 完璧主義の呪い。← 設計に捉われつづける。
- コードを人に見せることへのハードル。
- テスト駆動開発は、動作するコードを書いてからきれいにすることを教えてくれた。
-
- 開発において気付きが得られるタイミングは、動作する壁を越えた時。
-
-
- 動くけど汚いコードを綺麗にするには意思が必要。
- リファクタリングへの線を越えやすくする。
- そして細かく綺麗にする。
- ボーイ・スカウト理論
- キャンプに来た時は、来た時より綺麗にして帰る。
- プログラミングに応用する。チェックアウトしたら、次にチェックインする時には必ずどこか1つでも綺麗にする。
-
TDDのこころ
-
- 一つづつ、少しづつ
- テスト書く、コミット、コード書く、コミット、リファクタリング
- ToDoリストの粒度
- タスクを小さく割るというのはスキルであり、訓練により鍛えられるもの
- 一つづつ、少しづつ
-
- 一人づつ仕留める
- 宮本武蔵
- 1:nの戦いにどうやって対処するか。
- 1:1に分解する。
- 一番肝心なものから仕留めるとか、一番簡単なものから仕留める。
- 考えておくのは一つに絞る。
- 宮本武蔵
- 一人づつ仕留める
-
- 素早く回す
- テンポが大事。
- サイクルを素早く回す。
- 実行結果も可能な限り早く。
- 第一歩が小さい方がやりやすい
- 素早く回す
-
-
- (テストを書き初めるまでの時間は?)
-
-
- 自分が最初のユーザーに
- 先にテストコードを書く。自分が書いたコードの最初の利用者は自分になる。
- コードを書く人と使う人が分かれていることが良くある。
- そうすると、使いやすいかどうかを書く人が認識できない。
- 自分で利用するコードを書くことで、Why, Whatに気付くことが出来る。
- 作成者の脳から利用者の脳へ
- 先にテストコードを書く。自分が書いたコードの最初の利用者は自分になる。
- 自分が最初のユーザーに
-
-
-
- (テストしやすいコード ニアリー 使いやすいこーど?)
-
-
-
- 道具にこだわる
- コードを書くこと、テストと実装の切り替え、結果を早く表示するには。
- TDDに限らない。開発者として大事なこと。
- 道具にこだわる
-
- 不安をテストにする
- テストをどこまで書けばいいのか?
- 不安を克服できるように書く。
- 自分の手が止まる時はいつ。
- テストを書いて試す。
- 不安をテストにする
-
-
- 自分が分からないものは何かを見出す。
-
-
- 祈るのはダメ
- テストが無いから、祈りながらデプロイ押すのは辛い。
- やってみるまで分からない、なんてのはダメ。
- 祈るのはダメ
-
- テストは命綱
- 外部要因の変化に対応する。
- 事前に用意しているからこそ、急な要求に対応できる。
- ただし、義務感からではない。自分が安心できる状態をキープしたいと思っているからできること。
- テストは命綱
-
- なぜTDDをするか
- 自分は完璧ではない。
- 素早く近づきながら、フィードバックを得て陣地を広げキープし続けるために。
- なぜTDDをするか
-
- テストは目的ではなく手段
- 即座にフィードバックを得る
- 書いたコードに自信を持つ
- これから書くコードに自信を持つ。
- テストは目的ではなく手段
-
-
- TDDを実施する人が増えているのは、心理的な効果によるところが大きい。
-
-
- TDDの真の目的
- それは健康
- 変化に対応するには
- 健康体なコード
- 変更に対する影響範囲が分かる状態
-
- 健康体なチーム
-
- 気持ちに余裕が必要
- TDDの真の目的
事例
-
- TDDの導入効果(MS,IBM)
- TDDを採用しなかった場合、した場合の欠陥密度を比較する。
- 欠陥密度はかなり減少、一方でコード実装時間は増加する傾向。
- TDDを採用しなかった場合、した場合の欠陥密度を比較する。
- TDDの導入効果(MS,IBM)
-
-
- 偉い人に説明する際の、TDDのざっくりした言説に近い結果。
- 実装時間は2割増えて、バグが6割減る。
- 偉い人に説明する際の、TDDのざっくりした言説に近い結果。
-
応用
-
- テストの無いコードが沢山ある。
- レガシーコード改善ガイド
- 帯のアオリを考えたのは主催者のせとさん。
- 現場のカオスに立ち向かうために役に立つ本。
- 既にデータの入ったデータベースがある。サービス稼動中。
- データベースリファクタリング
- コードより変更がシビア
- テストが脆い
- テストが遅い
- 最長のテスト実行時間は3日間。
- テストの遅さが、TDDサイクルの遅さになる。
- xUnit test Patterns (凄い分厚い、900ページ)
- Growing Object-Oriented Software, Guide by Tests
- モックの概念を作った人が書いた本
- 次のTDDのバイブルになると思っている。
- #goos_jp 読書会実施中。
この先生きのこるために
-
- たくさん本を読む
- それぞれの書籍が示しているものは相互に繋がっている。
-
- テスト、TDDはスキルであり、訓練により鍛えられる。
- むしろ完璧じゃない凡人のためのもの。
- 練習量は質に転化する。写経大事。
-
- 技術書の写経の仕方
- 和田さんが昔書いたので、ググってみると。
- 技術書の写経の仕方
今日何か一つ覚えて帰るなら
-
- TDDと黄金の回転のイメージ
-
- 自分が書いたコードにテストを書くのは、
- プロとしての嗜み、という考えが自然になるようにしたい。
- 先にテストを書くのがめんどくさい時は誰にでもある。
- でもプロとしてやらねばならないこともある。