バグを確実に減らすことができるテストについてへの理解を深めて、テストの価値を理解して、テストを書くようになろう!!テストの書き方は他の資料に任せています。 (基本的にはUnityでのテストを書くことを想定しています) また、非エンジニアでもテストというものに理解ができるように説明するように心がけました。

1. テストを書こう!!

2. 目的
テストを書く意義を理解してもらう
テストを書く習慣を身につけてもらう

3. 目次
• バグとは?
• ソフトウェアの品質との関係性
• テストの種類と技法
• ユニットテスト概論
• ユニットテストの効用
• Unityにおけるユニットテストライブコーディング

4. みなさんテストしてますか?

5. 質問
自分が作った処理に、
絶対にバグがないと言いきれますか?
私は言い切れません

6. 開発者は昔からバグには悩まされてきました

7. 真理
• バグのないソフトウェアは無い
• 開発者はバグを生みたくはない
• バグは出ない事しか分からない
• バグを見つけるにはチェックをするしかない(=テスト)
• プログラムを修正したら、修正した分だけ、バグが発生する可能
性が高まる
• 機能を実装するためにはプログラムを修正しなければならない
• バグを修正するためにはプログラムを修正しなければならない

8. そもそもバグとは?
• 不具合のこと
• 開発者の意図とは異なる動作をするもの
バグ・欠陥を発見および修正し、動作を仕様通りのも
のとするための作業のことをデバッグという。
【参考】
https://ja.wikipedia.org/wiki/%E3%83%90%E3%82%B0
https://www.slideshare.net/UnityTechnologiesJapan/unite-2017-tokyounity

9. なぜバグが生まれてしまうのか?
バグは基本的に「(うっかり)ミス」が原因で生まれてしまう。

10. バグを減らすには?
各々気をつけろ!!という根性論ではバグは減りま
せん。
バグを科学して (理論的に分析して)、有効な手段
をとることでバグを減らすことができます。
筋トレの例

11. ソフトウェアにおける品質の関係
バグは人と時間をかけて
テストすれば多く「見つけ
る」ことができる。
ちなみに基本情報技術者試験(旧初級シス
アド)の頻出問題です。
https://www.jitec.ipa.go.jp/
「バグは出ない事しか分からない」ので、バグを見つけるためにはテストをする

12. ところで、みなさん、どうやってテストしていますか?

13. デグレード・エンバグ
• 見つけたバグを修正したら、バグが必ず減る…とは限らない。
• プログラムに修正を加えれば、また新たなバグを生むリスクが常に伴う。
【参考】http://e-words.jp/w/%E3%83%87%E3%82%B0%E3%83%AC%E3%83%BC%E3%83%89.html
このようデバッグしたはずなのに、新たにバグを生んでしまうことをデグ
レード(通称デグレ)やエンバグという

14. 正しいデバッグのフロー
バグがないかテストする
バグがあったので直す
バグが直ったかテストする。
デグレが起きていないかテストする。
バグがなくなったので次へ
チェックする必要がある項目数
バグがなくなった
バグがなくなった
バグがあった
バグがあった
…
1個
2個
同じ項目

15. この調子で開発終盤に至るころ
チェックする必要がある項目数 多すぎるっす!!
∞個

16. 開発終盤に至るころ
リリース
ライン
300人日
時間ない…時間ない…
バグ取りきれない…
例として数字を当ててみる
機能は全部実装した。
リリース1週間後、今ここ

17. そうならないためにどうしたらいいのか人類は考えました

18. 解決策
次からは「テスト」についてのお話
• 単調なことは人間がやるより、
機械がやる方が圧倒的に速
い
• 機械は決められたことをや
るぶんにはミスをしない

19. テストの種類と技法
• ユニットテスト(単体テスト)
• インテグレーションテスト(結合テスト)
• UIテスト(画面テスト)
• 機能テスト
• システムテスト
• ユーザによるテスト(受け入れテスト他)
など

20. 結合テスト
それぞれのテストの様子
ユニットテスト ユニットテスト ユニットテスト …
システムテスト
結合テスト 結合テスト 結合テスト …
システムテスト 受け入れテスト
作った側が行うテスト 発注(ユーザー)側が行うテスト
テスト名 テストケース例
ユニット
テスト
ガチャのレアアイテムの排
出確率が20%であるか?
結合テス
ト
ガチャ全体で正しく動作し
ているか?
システム
テスト
ゲーム全体(全ての機能)
が正しく動作しているか?
受け入れ
テスト
実際にゲームを遊んでみ
て面白いかどうか?

21. テストを自動化するためには?
テストの最小単位はユニットテスト
【ソフトウェア(プログラム)の基本】
プログラムは条件分岐(if文)の集まり
まずは少ない単位の条件分岐をテスト。
ユニットテストが作れる。

22. ユニットテストを自動化するためには?
ちなみに右のようなケースの場合: 「はい」を選んだ場合に起こるイベントは○○である。「いいえ」
を選んだ場合に起こるイベントは××である。etc といったテストを行う
ユニットテスト例
◯102 + 135 = 237 である → テストOK
×102 + 135 = 337 である → テストNG
これら全部確認していく処
理作れば自動化できそうで
すよね?
テスト実行
ボタン

23. ユニットテストを作るイメージ
テストケースの作成 = 試験問題の作成
テスト結果の作成 = 正解の番号を決める
テストのチェック = 採点機の作成

24. こういうテストはどうするの?
• 乱数を使う場合(想定している値が出てくるとは限らない)
• テストケース例: ガチャのレアアイテムの排出確率が20%であるか?
• 実際に処理を作ると: 0 ~ 99の間の乱数aが20より小さければ(a < 20)当たり
• 通信を使う場合(ちゃんと通信が成功するとは限らない)
• テストケース例: サーバーに通信して、通信が成功すればログインができるか?
• 実際に処理を作ると: 実際に通信してログイン成功の通信結果を取得したら、ログイン成功である。

25. スタブ・モック
なお
スタブ≒モック
双方は本来、違うものではあるんですが、ちょっと難しい話なので以下のリンクを参
照
http://qiita.com/7of9/items/8e2cb2070f2b2ea4e5ec
テスト用に用意した、まだ完成していない機能の代わ
りとなる部品のことをスタブという。
何を聞いても指定した結果を返すもの。
要するに

26. スタブ・モックを使った例
• 乱数を使う場合
• テストケース例: ガチャのレアアイテムの排出確率が20%であるか?
• 0 ~ 99の間の乱数aが必ず15を返すとする。この時はレアアイテムが当たる → テストOK
• 0 ~ 99の間の乱数aが必ず25を返すとする。この時はレアアイテムが当たらない → テストOK
• 通信を使う場合
• テストケース例: サーバーに通信して、通信が成功すればログインができるか?
• ログイン成功の通信結果を必ず取得できるとする。その場合、ログイン成功である。→ テストOK
• ログイン失敗の通信結果を必ず取得できるとする。その場合、ログイン失敗である。→ テストOK

27. テスト開発手法
• まずテストするテストケースを先に書
いてから、そのテストが動作する機
能をつくる開発手法をTDD(test-
driven development(テスト駆動開
発))という。
• 作ろうとする機能を要求仕様を整理
して、テストすべきケースを明記し、
テストを書きつつ、機能を作る開発
手法をBDD(behavior driven
development(ビヘイビア駆動開発))
という。 こういった開発手法がやりやすいかどうかはまた別の話

28. 網羅率(カバレッジ)
ソフトウェア開発において、出来上がったプログラ
ムのテストをする際に、どの程度をテスト対象とす
る(ことができる)か表したものを網羅率(カバレッ
ジ)(テストカバレッジ)という。
どれくらい、テストしてチェックができているか、定量
的に計測しよう、という考えではじき出されている数
字
なかなか定義が難しい、数字であったりします。。。

29. カバレッジに関する一般論
ではカバレッジ100%じゃないとリリースできないらしい。。。
• 割としっかりとユニットテストを書くと大体カバレッジは60%〜80%
前後くらいになります。(書いている人の性格によります)
カバレッジ100% → 入学試験で100点満点とるようなイメージです。

30. ユニットテストを導入している会社一例
http://labs.gree
.jp/blog/2015/1
2/15392/
GDCのセッショ
ンにて
http://d.hatena.ne.jp/nakamura0
01/20120301/1330618355
まぁ、大きい所はみん
なやっているよね…
…
経験上、小さい組織ではやっていないような気がします…
http://tech.cyga
mes.co.jp/archi
ves/2937/

31. ユニットテスト導入するメリット・デメリット
【メリット】
• デグレが発生しなくなる。 → デバッグしたら確実にバグが減る
• 長期的にみると開発時間が短縮される。
• 書いてあって困ることがなくて、書いてあればそのぶんだけ効果がある。
【デメリット】
• テストを書くためには一定以上のスキルを求められる
• 短期的にみると開発時間が増える
• 効果がすぐにわかるものではない
• めんどくさい
• エラーがでるとうざい
開発者のモチベーションにつなが
りにくい
(私も仕事じゃなかったら書かない…)
ちなみに変更したらその都度直さないといけないと
よく言われるが、
これはデグレが発生しないということと裏表の話

32. テストにおけるアンチパターン
【参考】 https://www.slideshare.net/wterada/ss-31623012
処理を修正した
知らないところでエラーが出た
テストを直して、テストを通した
デグレ発生
なぜエラーが出たのか
ちゃんと調べましょう!!!!

33. ユニットテスト向いている/向いていないケース
【ユニットテストをするのに向いているケース】
• 処理が複雑であるもの
• 機能がどんどん追加されるもの(運用していくもの)
• 複数人が修正するもの
【ユニットテストをするのに向いていないケース】
• 表示関係

34. ユニットテストについての諸説
• ユニットテストを書いたからといってバグが0になる
わけではありません!! (実際に動かして触ってみるテ
ストも必要です)
• テストの有無は自分の作った処理にバグがないとい
う客観的な信用にもつながります
• ユニットテストの導入というのはチームとしての文化
の話も含まれるので協力が必要。
• 経験上、チームの中で「テスト書け!!」と言って、ルー
ル化して、推し進めていかないと、文化としてなかな
かテストが書かれるようにはならない。

35. ユニットテスト導入の違いをグラフで表してみる
0
0.5
1
1.5
2
2.5
3
3.5
1週 2週 3週 4週
開発期間と進捗具合の関係
ユニットテストなしの場合 ユニットテストを書いている場合

36. ユニットテスト導入の違いをグラフで表してみる
0
10
20
30
40
50
60
70
80
90
1日目 2日目 3日目 4日目 5日目
デバッグ期間と品質(バグの少なさ)の関係
ユニットテストなしの場合 ユニットテストありの場合

37. ユニットテスト導入の違いをグラフで表してみる
0
1
2
3
4
5
6
1日目 2日目 3日目 4日目 5日目 6日目 7日目 8日目 9日目
新機能開発時の進捗具合の関係
ユニットテストなしの場合 ユニットテストありの場合

38. UNITYにおけるテストについて
詳しくはこちら他
• https://www.slideshare.net/UnityTechnologiesJapan/unit
e-2017-tokyounity
• https://www.slideshare.net/hirotoimoto1/unityunittest

39. 実際にテストを書いてみよう!!
ライブコーディングデモします。m(_ _)m

40. 最後に
• ユニットテストを書くことは現状で唯一の確実にバグを減らせる方法です。
• ユニットテストを書いたら、自信を持って堂々と「私の作ったプログラムにバ
グなんてない！」と言えるようになります。
• ユニットテストを書いていると切羽詰まっている時に書いていてよかったと
思えるようになります。
• ほんの少しづつでもいいので、ユニットテストを書いていきましょう!!