オトナのプログラミング勉強会で2018年2月21日に開催されたテスト駆動開発(TDD)についての資料です。

1. オトナの
TDD入門
オトナのプログラミング勉強会
2018年2月21日
山ノ内祥訓

2. 自己紹介
名前
年齢
住まい
お仕事
山ノ内 祥訓(よしのり)
0x26
熊本県
現在は某大学病院の特任助教で臨床研究のデータ
マネージャとして主に臨床研究データに関する設
計及び開発と運用をやっています。
某SIerで医療情報システムの導入及び開発を10年
ぐらいやっていました。
SNS Facebook https://www.facebook.com/yoshinori.yamanouchi.12
Github https://github.com/eolla1013
資格等 修士（医科学） 現在博士課程
医療情報技師
Yoshinori Yamanouchi

3. 今日のお話
テスト駆動開発(TDD)の概要
TDDの実践
実際の開発現場でのTDD

4. テスト駆動開発とは
Test Driven Development
プログラム開発手法の一種で、プログラムに必要な各機能に
ついて、最初にテストを書き（これをテストファーストと言
う）、そのテストが動作する必要最低限な実装をとりあえず
行った後、コードを洗練させる、という短い工程を繰り返す
スタイルである。多くのアジャイルソフトウェア開発手法、
例えばエクストリーム・プログラミングにおいて強く推奨さ
れている。
(Wikipediaより引用)

5. TDDのきっかけ
テスト駆動開発
オブジェクト指向
設計
プログラムの大規模化
(複雑化)
アジャイル開発
ものの本によるとTDDの最初は1957年だそうな・・・

6. プログラムの大規模化(複雑化)
• プログラムが大規模化するにつれて開発効率を高め
るためにレイヤ化や部品化が進んだ。
• 実装したプログラムをテストするにはすべての部品
がそろわなければできない。
• バグがどの部品にあるか調査に時間がかかる。表面
上バグがあっても埋もれてしまう。
実装 実装 実装 実装
テ
ス
ト
View Controller Model Database

7. オブジェクト指向設計
• 構造化設計では対応できない規模のソフトウェア開
発を行うために使用されはじめた。
• カプセル化、継承、多態といったオブジェクト指向
プログラミングの要素を使用したレイヤ間、部品間
の疎結合が簡単にできるようになった。

8. アジャイル開発
• 仕様を固定せず必要な機能だけを優先順位をつけて
順次開発していくことで本来必要なものに近いシス
テムが開発できる。が、繰り返し開発を行うため影
響度調査やテストの負荷が高くなった。
• ウォーターフォール開発では仕様を最初に固定し最
後に完成物が引き渡されるため仕様の齟齬が発生し
やすく、本来必要なものが開発できずトラブルにな
ることが多かった。
設計
実装
テスト
リリース

9. 実装時に品質を高める
• 必要な部品を全て作った後にテストするのではなく、
部品ごとにテストを行えれば・・・
• 他の人の作った部品をどうやって使うのかがわから
ない・・・
• 機能の変更や追加で他に影響が出ていないか調べる
時間が足りない・・・
そこでテスト駆動開発！！

10. TDDの流れ
 新規実装・実装変更の場合
①新しいテストをテストコードとして実装。
②テストを実行し新しいテストが失敗することを確認
(逆にそれ以外のテストは成功することも確認する)。
③プロダクトコードを実装してテストを実行し新しい
テストが成功することを確認。
④リファクタリングを実施しプロダクトコードを改善。

11. TDDの流れ
 リファクタリングの場合
①テストを実行しすべてのテストが成功することを確認。
②プロダクトコードをリファクタリングする。
③テストを実行しすべてのテストが成功することを確認。
④テストが失敗したらどこかに変更箇所の影響が及んでい
るのでそれを変更しすべてのテストが成功すれば完了。

12. TDDで使われるツール
 ユニットテストフレームワーク
「xUnit」という名前で呼ばれるテスト用のフレーム
ワーク。Xには各言語の名前が入ることで多くの言語で
同じような使い方ができる。
 継続的インテグレーションツール(CI)
実装からテストまでを自動実行し統合管理するための
ツール。最近はリリース作業となるデプロイまで含めた
CI/CDと呼ばれる。

13. TDDの注意点
 検証プロセスとしてのテストと一緒にしない
あくまでTDDで実装されたテストコードは、実装中に動
作が不安なプロダクトコードをなくし、プロダクトコー
ドが変更で壊れないことを確認するためのもの。副次的
に検証プロセスの一部として使える場合もある(カバレッ
ジや再帰テスト)がそれを目的にしない。
 最初にすべての仕様に対するテストを書かない
TDDのキモは細かく実装しそのテストを実行して確認を
繰り返すことでプロダクトコードを成長させること。仕
様が分かっているからといって最初に全部書かない。

14. では実践してみましょう
配布されたアカウントでCloud9にログインして、
pythonの新規プロジェクトを作成してください。

15. 準備
テストコードを実装するファイルとプロダクト
コードを実装するファイルの2つ作成します。
tddhandson.py
tddhandson_test.py
プロダクトコード
(実際にシステムで使うコード)
テストコード
(プロダクトコードをテストする
ためのコード)
※多くの場合はフォルダを分けますが
今回は一緒のフォルダに置きます。

16. お題「FizzBazz」
二つの整数を渡すとその間の整数を全て文字列配列
で返す。ただし、整数が3で割り切れる場合
は”Fizz”、5で割り切れる場合は”Bazz”、3と5で割
り切れる場合は”FizzBazz”に置き換えること。
実装するクラスは「FizzBazzCreator」、
使用するメソッドは「create」とする。

17. テストコードの実装(0)
Pythonのユニットテストフレームワークとして
「unittest」があります。これを実装して実行して
みます。
実行すると「FAILD」と表示されると思います。これ
を「OK」になるようにテストコードを修正しましょう。

18. プロダクトコードの実装(0)
お題に記載した通りクラスとメソッドを定義します。
実装は空でOKです。

19. テストコードの実装(1-1)
仕様として一番最小のもののテストを実装します。
仕様は「二つの整数の差の数分の要素を持つリスト
が返ってくること」です。
実装後実行してみてください。
TypeError: object of type 'NoneType' has no len()
というエラーでFAILDになるはずです。

20. プロダクトコードの実装(1-2)
テストコードが成功するようにプロダクトコードを
実装します。

21. テストの実行(1-3)
テストを実行し成功することを確認します。

22. テストコードの実装(2-1)
次の仕様は「配列に整数が文字列として順番通り並
んでいること」です。
実装後実行してみてください。
AssertionError: '' != '1'
というエラーでFAILDになるはずです。

23. プロダクトコードの実装(2-2)
テストコードが成功するようにプロダクトコードを
実装します。

24. テストの実行(2-3)
テストを実行し成功することを確認します。

25. テストコードの実装(3-1)
次の仕様は「3で割り切れる要素は”Fizz”であるこ
と」です。
実装後実行してみてください。
AssertionError: '3' != 'Fizz‘
というエラーでFAILDになるはずです。

26. プロダクトコードの実装(3-2)
テストコードが成功するようにプロダクトコードを
実装します。

27. テストの実行(3-3)
テストを実行し成功することを確認します。

28. テストコードの実装(4-1)
次の仕様は「5で割り切れる要素は”Bazz”であるこ
と」です。
実装後実行してみてください。
AssertionError: ‘5' != 'Bazz‘
というエラーでFAILDになるはずです。

29. プロダクトコードの実装(4-2)
テストコードが成功するようにプロダクトコードを
実装します。

30. テストの実行(4-3)
テストを実行し成功することを確認します。

31. テストコードの実装(5-1)
最後の仕様は「3と5で割り切れる要素は”FizzBazz”
であること」です。
実装後実行してみてください。
AssertionError: ‘Bazz' != ‘FizzBazz‘
というエラーでFAILDになるはずです。

32. プロダクトコードの実装(5-2)
テストコードが成功するようにプロダクトコードを
実装します。

33. テストの実行(5-3)
テストを実行し成功することを確認します。

34. リファクタリング
今回のお題はそんなにリファクタリングする個所も
ないので省略。実際は仮実装も多いのでリファクタ
リングを行います。
また、仕様自体に抜けがある場合が見つかった時は
追加でテストを書いておきます(今回の例ではa<b
であること、とか)。

35. 実際の開発現場での例
今回のハンズオンではロジックだけなので簡単です
が実際のシステムは多くの要素が絡まりTDDを実践
しにくいことがあります。
そんな時どうやってユニットテストを行っているか
パターン別に紹介します。

36. データベースアクセス
 何が厄介なのか
 対応策
• データベースがないとテストができない。
• データが永続化されるのでテストの独立性が保た
れない。
似たような事例として通信やファイル入出力がある。
• データベースとのやり取りを別クラスとする
(Repositoryパターン等)。
• ユニットテスト用のモックオブジェクトを作る。
• データベースアクセス専用のテストフィーチャー
を別に作る。
• 各テストの開始終了でDBのロードとクリアを行う。

37. ユーザインターフェース
 何が厄介なのか
 対応策
• 人が画面で操作することが前提。
• 操作前後の表示の違いを把握する必要がある。
• 画面は表示と操作受付の最小限実装とし実際は別
クラスで実装する(ViewModelパターン等)。
• UIテストフレームワークを使用する。
• あきらめる(そもそもTDDは検証用ではない)。

38. 並列処理
 何が厄介なのか
 対応策
• 動作順が不定なので決められた動作をしない。
• 並列処理は他のスレッドに影響が出ないように設
計する。
• 直列処理を行うようなモックオブジェクトを作り
順番を変えてテストする。
• 並列処理のテストを何百回も実行するようなテス
トを別のテストフィーチャーとして作る(運任せ)。

39. プライベートメソッド＆フィールド
 何が厄介なのか
 対応策
• テスト側から呼び出すことができない。
• テストしたいメソッドやフィールドはprivateにせ
ずprotectedとし、継承したモックオブジェクトで
テストする。
• ユニットテストフレームワークによってはこれに
対応する機能があったりする。
• リフレクションを使用する。

40. テストの粒度
 何が厄介なのか
 対応策
• どこまでテストを書けばわからない。
• 実装中に気になる処理だけを書く。
• 途中経過を確認したい処理だけ書く。
• テスト実行時にカバレッジが80～90%ぐらいにな
るまで書く。
一般的なテスト項目はTDDとして実装しない！！

41. まとめ
名前で誤解されることの多いTDDですが、実装の質と効率を
上げる役割を持っています。そのため、TDDではなく振る舞
い駆動開発(Behavior Driven Development;BDD)という名
前で呼ぶ人もいます。
BDDでは、TDDから一歩進んでテストコードがクラス仕様書
の代わりとなり、そのクラスを使う人に対してどうやって使
えばよいかを示すことも求められてきます(テストコードのコ
メントに仕様の説明や注意点を書いたりする)。
というわけで皆さん使っていきましょう！！