自動テストについて思っているところをつらつらと社内LTで発表した内容です。どこまで自動化できて、どこからは人の手でテストしないといけないかはプロジェクトの性質にもよると思いますが、基本的に自動化できるものは自動化していきたいところ。

1. テストとの
上手な付き合い方
株式会社ファクトリアル
末並 晃

2. 最近考えてることを
つれづれなるままに話します。

3. 知ってもらいたいこと
• 非エンジニア
• どういうことは自動化できて、どういうところは人の手が必要か
• エンジニア
• テストコードの保守性
• テスト駆動設計（Test Driven Design: TDD）
• 全員
• 「最近、テストのことばかり考えてます」と言ってますが、決し
て苦学生なわけではない

4. こんくるーじょん
ふぁーすと

5. 自動テストを意識す
ると幸せになれる
（かも）。

6. 最近読んだ本

7. テストの種類
• 単体テスト
• 結合テスト
• 受け入れテスト
• キャパシティテスト
• その他…
よくわからん！

8. テストの分類
• 目的による分類
• 開発プロセスの効率化・開発支援
• 製品の品質評価
• テストする視点の違いによる分類
• ビジネス的視点
• 技術的視点

9. ブライアン・マリックのテストの四象限
ビジネス視点
ショーケース
機能の受け入れテスト ユーザビリティテスト
開 探索的テスト 製
発 品
支 評
援 ユニットテスト 価
インテグレーションテスト 非機能の受け入れテスト
システムテスト
技術視点
出典: 継続的デリバリー ( http://www.amazon.co.jp/dp/4048707876 )

10. テストファーストってどう？

11. テストファーストとは
• テスト駆動開発の核となる考え方
• プロダクトコードよりも先にテストコードを実装する
• テスト駆動開発 (てすとくどうかいはつ、test-driven development; TDD) とは、プログラ
ム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き（こ
れをテストファーストと言う）、そのテストが動作する必要最低限な実装をとりあえ
ず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。多く
のアジャイルソフトウェア開発手法、例えばエクストリーム・プログラミングにおい
て強く推奨されている。近年はビヘイビア駆動開発へと発展を遂げている。

12. もちろんテストファーストはよい考え方
• 必然的にブラックボックステストになる
• プロダクトコードの内部構造に依存しないテストコー
ドが書ける
• 注目していなかった要件・仕様に気づく機会になる
• 特に異常系の処理

13. でも

14. TDDが向いていない
プロジェクトやシチュエーションも
あります。
（というか、そのほうが多いかもw）

15. TDDが向かないプロジェクト／シチュエーション
• 開発初期段階で詳細な仕様が決まっていない
• とりあえず動くものがないとイメージがわかない
• テストを書くまでもないシンプルな仕様である
• 継続的な追加開発などが期待できない

16. テストを書くということ
• 回帰（リグレッション）テスト
• 思わぬ不具合をに気づくことができる
• ドキュメントとしてのテスト
• テストコードを見ればテスト対象の役割がわかる
• ドキュメントのためのドキュメントでなく、実際に動くドキュメント
• リファクタリング
• プログラムの振舞を変えずに構造を変更する
• テストしやすい設計
• 実際にテストが書かれているかどうかに関わらず、「テストしやすい」コードはよ
い設計である

17. テストしやすい設計
• オブジェクト指向
• 適切な粒度のモジュール化
• 明確で簡潔なインターフェース
• Dependency Injection
• 依存関係は外部から差し込む
• 内部状態に依存せず、結果が非決定的にならないよう
にする

18. テストファーストが
絶対ではない（と思う）

19. テストコードを意識することに
意味がある。

20. テスト厨になると
プロダクトコードを実装しているときでも
「これ、テストしにくそう。。orz」
とか考えるようになる。
（絶賛感染中）

21. ブライアン・マリックのテストの四象限（再掲）
ビジネス視点
ショーケース
機能の受け入れテスト ユーザビリティテスト
開 探索的テスト 製
発 品
支 評
援 ユニットテスト 価
インテグレーションテスト 非機能の受け入れテスト
システムテスト
技術視点
出典: 継続的デリバリー ( http://www.amazon.co.jp/dp/4048707876 )

22. 機能の受け入れテストの自動化／テストファースト
• 受け入れ基準（＝要件）の明確化
• 受け入れテストは顧客の言葉で書く
• http://cukes.info/
• http://behat.org/
• 動くドキュメント（２回目）
• 回帰テスト

23. まとめ
• 自動化できるテストは自動化する
• 必ずしもテストを先に書く必要はなく、「あとでテスト
書こう」と思うだけでも意識が変わる
• 受け入れテストも自動化できる
• そして継続的デリバリーへ

24. シリーズ化したい
• テストダブル
• ダミー、フェイク、スタブ、モック
• fragile test 問題
• ある程度の規模以上になるとテストを保守するため工
数がかかる
• 開発フレームワークの設計
• プロジェクト管理
• デプロイメントパイプライン

25. ご清聴
ありがとうございました