社内勉強会で使った資料です

1. アプリのテストを書かなければな
らないと分かっているけども、書
けていない人たちへ
山崎友弘

2. そもその何の為にテストを書く
の？
・仕様変更、追加に耐えうる為

3. ということは今後100%仕様変更、
追加がないと分かっている場合
はテストを書く必要がない。

4. しかし、残念ながら未来のことは
分からないので、テストを書かな
ければならない。

5. 「テストコードとは保険
の様な物だ」

6. サーバーのテストは一般的になっ
てるけど、アプリのテストって浸透
してない気がするけどなぜ？

7. 1.プロダクトの寿命が短い
サーバーと比べると、アプリのプ
ロダクトの寿命は短いので、そこ
まで保険を掛ける必要がない。

8. 2.サーバーのテストでは
保険以外の価値が・・・
これ重要なので、深堀して説明
します。

9. サーバーのAPIのテストをしようと
すると
・DBの値が、この場合とこの場合
とこの場合と・・・
・getのテスト用urlを作る為に、api
仕様書みなきゃ
・postのapiテストどうしよう

10. これを解決するのが

11. テストコード！！

12. サーバーのテストコードの価値は
は保険だけではない

13. 今の作業が楽になる

14. だからサーバーのテストコードは

15. 「書かなければならない」
ではなく

16. 「書きたい」
になっている

17. 今日のねらい
アプリのテストコードも
「書かなかればならない」
ではなく
「書きたい」
にもっていく

18. まずテストを書く前に大事なこと
・テスタビリティ(試験性)なコード
であるか

19. テスタビリティの特徴
・クラスおよびメソッドが適切な
サイズに分割されている
・入力と出力が明確である

20. なぜテスタビリティでないコードで
テストが書けないか
実際にコードを見てみよう

21. こんなアプリのコードです
「更新」ボタンを押したら
テーブルQiitaのAPIを
叩いて返ってきたデータを
テーブルビューに表示してい
るだけのものです。

22. まず悪いコード例

23. 「更新」ボタンのイベント

24. テストしようとすると・・・
・このメソッドのアウトプットが曖昧すぎて何を
確認したらよいか分からない
・VとMが分離されていないからこういうことが
起きる

25. ナイスなコード例

26. 「更新」ボタンの中身を
モデルに任せました

27. するとテストが書ける様に
なりました
・VとMが分離し、アウトプットが明確になった
ため、 テストが書ける様になった。

28. 新たに出てきた疑問
・ネットワークの通信系のエラー処理どうしよう？
・どこに書けばいいかな？
・同じところに書くのはテストのレイアーが違う
気がしない？

29. パーフェクトなコード例

30. 「updateQiitaList」の中身
・通信部分は他でも汎用的に使えそう
・以下の赤枠の部分がこのモデルに依存している
・じゃー、切り分ければいいじゃん

31. 通信部分だけ汎用的なModelと
して抜き出しました

32. すると、通信のエラー処理のテストコードは、この
モデルのテストクラスでしてあげれば他の場所で
する必要がない

33. 結果、それぞれのメソッドの粒度
に最適なテストだけを書くことが
出来ました。
めでたしめでたし
ソースアップしてます：
悪い例:https://github.com/yamasakitomohiro/QiitaList_bad
ナイスな例：https://github.com/yamasakitomohiro/QiitaList_nice
パーフェクトな例：https://github.com/yamasakitomohiro/QiitaList_perfect

34. テスタビリティでないとダメな理由
・結果として何を確認すべきか
曖昧過ぎて分からない
・テスタビリティ＝＝良い設計

35. テストコード書くと良いこと

36. 『メソッドが何処まで考えて作られ
ているかが一目でわかる！！』
特にイレギュラー系

37. 例えばこんな感じ

38. 『MVCが良くわからなければ
テストコードを書けばいい』

39. モデルが分離できていないとテス
トコードが書きにくいので、自然と
分離するようになる。

40. 『コードを修正する時に、あれこれ
考えなくてよく不安がない』
デグレってもテストコードが
拾ってくれるから安心！

41. 『必然的に、
設計を見直すことになるので
バグを発見しやすい』

42. 『テストを書けると出来る
エンジニアっぽくなる』

43. 『品質を証明する
ドキュメントになる』

44. テスト書きたくなりました？