Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
アプリのテストを書かなければな
らないと分かっているけども、書
けていない人たちへ	
山崎友弘
そもその何の為にテストを書く
の?	
・仕様変更、追加に耐えうる為
ということは今後100%仕様変更、
追加がないと分かっている場合
はテストを書く必要がない。
しかし、残念ながら未来のことは
分からないので、テストを書かな
ければならない。
「テストコードとは保険
の様な物だ」
サーバーのテストは一般的になっ
てるけど、アプリのテストって浸透
してない気がするけどなぜ?
1.プロダクトの寿命が短い	
サーバーと比べると、アプリのプ
ロダクトの寿命は短いので、そこ
まで保険を掛ける必要がない。
2.サーバーのテストでは
保険以外の価値が・・・	
これ重要なので、深堀して説明
します。
サーバーのAPIのテストをしようと
すると	
・DBの値が、この場合とこの場合  
 とこの場合と・・・
・getのテスト用urlを作る為に、api
 仕様書みなきゃ	
・postのapiテストどうしよう
これを解決するのが
テストコード!!
サーバーのテストコードの価値は
は保険だけではない
今の作業が楽になる
だからサーバーのテストコードは
「書かなければならない」
ではなく
「書きたい」
になっている
今日のねらい	
アプリのテストコードも
「書かなかればならない」
ではなく
「書きたい」
にもっていく
まずテストを書く前に大事なこと	
・テスタビリティ(試験性)なコード
であるか
テスタビリティの特徴	
・クラスおよびメソッドが適切な
 サイズに分割されている
・入力と出力が明確である
なぜテスタビリティでないコードで
テストが書けないか
実際にコードを見てみよう
こんなアプリのコードです	
「更新」ボタンを押したら
テーブルQiitaのAPIを
叩いて返ってきたデータを
テーブルビューに表示してい
るだけのものです。
まず悪いコード例
「更新」ボタンのイベント
テストしようとすると・・・	
・このメソッドのアウトプットが曖昧すぎて何を
確認したらよいか分からない
・VとMが分離されていないからこういうことが
起きる
ナイスなコード例
「更新」ボタンの中身を
モデルに任せました
するとテストが書ける様に
なりました	
・VとMが分離し、アウトプットが明確になった
ため、 テストが書ける様になった。
新たに出てきた疑問	
・ネットワークの通信系のエラー処理どうしよう?
・どこに書けばいいかな?
・同じところに書くのはテストのレイアーが違う
 気がしない?
パーフェクトなコード例
「updateQiitaList」の中身	
・通信部分は他でも汎用的に使えそう
・以下の赤枠の部分がこのモデルに依存している
・じゃー、切り分ければいいじゃん
通信部分だけ汎用的なModelと
して抜き出しました
すると、通信のエラー処理のテストコードは、この
モデルのテストクラスでしてあげれば他の場所で
する必要がない
結果、それぞれのメソッドの粒度
に最適なテストだけを書くことが
出来ました。
めでたしめでたし	
ソースアップしてます:
 悪い例:https://github.com/yamasakitomohiro/QiitaList_bad
 ナイスな例...
テスタビリティでないとダメな理由	
・結果として何を確認すべきか	
 曖昧過ぎて分からない	
	
・テスタビリティ==良い設計
テストコード書くと良いこと
『メソッドが何処まで考えて作られ
   ているかが一目でわかる!!』	
特にイレギュラー系
例えばこんな感じ
『MVCが良くわからなければ
    テストコードを書けばいい』
モデルが分離できていないとテス
トコードが書きにくいので、自然と
分離するようになる。
『コードを修正する時に、あれこれ
考えなくてよく不安がない』	
デグレってもテストコードが	
     拾ってくれるから安心!
『必然的に、
設計を見直すことになるので
バグを発見しやすい』
『テストを書けると出来る
    エンジニアっぽくなる』
『品質を証明する
   ドキュメントになる』
テスト書きたくなりました?
Upcoming SlideShare
Loading in …5
×

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

7,831 views

Published on

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

Published in: Technology
  • Be the first to comment

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

  1. 1. アプリのテストを書かなければな らないと分かっているけども、書 けていない人たちへ 山崎友弘
  2. 2. そもその何の為にテストを書く の? ・仕様変更、追加に耐えうる為
  3. 3. ということは今後100%仕様変更、 追加がないと分かっている場合 はテストを書く必要がない。
  4. 4. しかし、残念ながら未来のことは 分からないので、テストを書かな ければならない。
  5. 5. 「テストコードとは保険 の様な物だ」
  6. 6. サーバーのテストは一般的になっ てるけど、アプリのテストって浸透 してない気がするけどなぜ?
  7. 7. 1.プロダクトの寿命が短い サーバーと比べると、アプリのプ ロダクトの寿命は短いので、そこ まで保険を掛ける必要がない。
  8. 8. 2.サーバーのテストでは 保険以外の価値が・・・ これ重要なので、深堀して説明 します。
  9. 9. サーバーのAPIのテストをしようと すると ・DBの値が、この場合とこの場合    とこの場合と・・・ ・getのテスト用urlを作る為に、api  仕様書みなきゃ ・postのapiテストどうしよう
  10. 10. これを解決するのが
  11. 11. テストコード!!
  12. 12. サーバーのテストコードの価値は は保険だけではない
  13. 13. 今の作業が楽になる
  14. 14. だからサーバーのテストコードは
  15. 15. 「書かなければならない」 ではなく
  16. 16. 「書きたい」 になっている
  17. 17. 今日のねらい アプリのテストコードも 「書かなかればならない」 ではなく 「書きたい」 にもっていく
  18. 18. まずテストを書く前に大事なこと ・テスタビリティ(試験性)なコード であるか
  19. 19. テスタビリティの特徴 ・クラスおよびメソッドが適切な  サイズに分割されている ・入力と出力が明確である
  20. 20. なぜテスタビリティでないコードで テストが書けないか 実際にコードを見てみよう
  21. 21. こんなアプリのコードです 「更新」ボタンを押したら テーブルQiitaのAPIを 叩いて返ってきたデータを テーブルビューに表示してい るだけのものです。
  22. 22. まず悪いコード例
  23. 23. 「更新」ボタンのイベント
  24. 24. テストしようとすると・・・ ・このメソッドのアウトプットが曖昧すぎて何を 確認したらよいか分からない ・VとMが分離されていないからこういうことが 起きる
  25. 25. ナイスなコード例
  26. 26. 「更新」ボタンの中身を モデルに任せました
  27. 27. するとテストが書ける様に なりました ・VとMが分離し、アウトプットが明確になった ため、 テストが書ける様になった。
  28. 28. 新たに出てきた疑問 ・ネットワークの通信系のエラー処理どうしよう? ・どこに書けばいいかな? ・同じところに書くのはテストのレイアーが違う  気がしない?
  29. 29. パーフェクトなコード例
  30. 30. 「updateQiitaList」の中身 ・通信部分は他でも汎用的に使えそう ・以下の赤枠の部分がこのモデルに依存している ・じゃー、切り分ければいいじゃん
  31. 31. 通信部分だけ汎用的なModelと して抜き出しました
  32. 32. すると、通信のエラー処理のテストコードは、この モデルのテストクラスでしてあげれば他の場所で する必要がない
  33. 33. 結果、それぞれのメソッドの粒度 に最適なテストだけを書くことが 出来ました。 めでたしめでたし ソースアップしてます:  悪い例:https://github.com/yamasakitomohiro/QiitaList_bad  ナイスな例:https://github.com/yamasakitomohiro/QiitaList_nice パーフェクトな例:https://github.com/yamasakitomohiro/QiitaList_perfect
  34. 34. テスタビリティでないとダメな理由 ・結果として何を確認すべきか  曖昧過ぎて分からない ・テスタビリティ==良い設計
  35. 35. テストコード書くと良いこと
  36. 36. 『メソッドが何処まで考えて作られ    ているかが一目でわかる!!』 特にイレギュラー系
  37. 37. 例えばこんな感じ
  38. 38. 『MVCが良くわからなければ     テストコードを書けばいい』
  39. 39. モデルが分離できていないとテス トコードが書きにくいので、自然と 分離するようになる。
  40. 40. 『コードを修正する時に、あれこれ 考えなくてよく不安がない』 デグレってもテストコードが      拾ってくれるから安心!
  41. 41. 『必然的に、 設計を見直すことになるので バグを発見しやすい』
  42. 42. 『テストを書けると出来る     エンジニアっぽくなる』
  43. 43. 『品質を証明する    ドキュメントになる』
  44. 44. テスト書きたくなりました?

×