OHHTTPStubsを使ったiOSアプリ開発

  • 4,315 views
Uploaded on

スタートアップ勉強会 #3で発表した資料です

スタートアップ勉強会 #3で発表した資料です

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,315
On Slideshare
0
From Embeds
0
Number of Embeds
8

Actions

Shares
Downloads
2
Comments
0
Likes
6

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. OHHTTPStubsを使ったiOSアプリ開発 株式会社キュリオシティソフトウェア! @yimajo スタートアップiOS勉強会 #3
  • 2. 自己紹介 ❖ (株)キュリオシティソフトウェア 今城 善矩! ❖ まったりiOSアプリの受託開発をしているので仕事の 話があれば相談に乗れる体制ですよ
  • 3. 本題のOHHTTPStubsについて 2つのプロジェクトで使ってみた
  • 4. OHHTTPStubsとは ❖ iOSアプリの通信を内部でフックしてスタブ用のレスポ ンスを返すライブラリ ☓
  • 5. OHHTTPStubsとは ❖ 単体テストのためにプログラムを書き換える必要もない
  • 6. OHHTTPStubsとは ❖ ステータスコードを任意に変更もできるので異常系の確 認できる! ❖ レスポンス時間を長くして電波が悪い状況を作り出せる
  • 7. OHHTTPStubsとは ❖ 他のライブラリを組み合わせてテスト自動化もできる! ❖ そういうのよくある話なので今回の話には含まない
  • 8. 最強のメリットは
  • 9. APIがまだ出来てなくてもAPIと の連携部分を単体テスト出来る
  • 10. そもそもの開発フローを 振り返ると
  • 11. APIの仕様決め API実装 全体の仕様決め APIを開発環境に順次デプロイ APIの実動作確認 API連携部分の開発フロー
  • 12. APIの仕様決め API実装 全体の仕様決め APIを開発環境に順次デプロイ APIの実動作確認 API連携部分の開発フロー
  • 13. APIの仕様決め API実装 全体の仕様決め APIを開発環境に順次デプロイ APIの実動作確認 API連携部分の開発フロー
  • 14. APIの仕様決め API実装 全体の仕様決め APIを開発環境に順次デプロイ APIの実動作確認 API連携部分の開発フロー
  • 15. APIの仕様決め API実装 全体の仕様決め APIを開発環境に順次デプロイ APIの実動作確認スタブで実装を進められる API連携部分の開発フロー
  • 16. APIの仕様決め API実装 全体の仕様決め APIを開発環境に順次デプロイ APIの実動作確認 API連携部分の開発フロー
  • 17. APIの仕様決め API実装 全体の仕様決め APIを開発環境に順次デプロイ APIの実動作確認 API連携部分の開発フロー
  • 18. APIの仕様決め API実装 全体の仕様決め APIを開発環境に順次デプロイ APIの実動作確認 API連携部分の開発フロー
  • 19. APIの仕様決め API実装 全体の仕様決め APIを開発環境に順次デプロイ APIの実動作確認 API連携部分の開発フロー
  • 20. APIの仕様決め API実装 全体の仕様決め APIを開発環境に順次デプロイ APIの実動作確認スタブでプロトタイプを作れる API連携部分の開発フロー
  • 21. 他に使ってみて良かったこと もあるよ
  • 22. 良かったこと API開発者にエクセル方眼紙で! API仕様書を作ってもらったとき! jsonとしておかしい仕様になっていたり! 打ち合せと違ったりなんていうものが! 作られる時あるじゃないですか
  • 23. 良かったこと そういう仕様書に対して! 「これjsonパース出来ないっすよね?」! 「打ち合わせと微妙に違ってませんか?」! みたいなレビューするのすごく気を使う
  • 24. 良かったこと 結局はtypoだったりなので! API開発者が実装してみたら気づくだろうな! みたいな
  • 25. 良かったこと まずはjsonとして正しい状態で! アプリ開発者に渡してくれるだけでも! 些末な指摘をしなくて良くなる
  • 26. 使ってみて良くなかったこと もあるよ
  • 27. 良くなかったこと 「スタブがあるならAPIの実装遅れてるけど間に合うよね?」
  • 28. 良くなかったこと APIの実動作の確認が遅れたり! 結合させたとき生じる何かしらの課題に! 気づく時間が短くなる事はリスクになるよ!
  • 29. その他の気づいたこととかも あるよ
  • 30. リリースビルドに含めないように OHHTTPStubsなどテスト用の! フレームワークやライブラリは! 当然リリースビルドに含めたら駄目なので! リリースビルドでは絶対除外するように仕込む
  • 31. リリースビルドに含めないように そのときの除外の仕組みを! プリプロセッサマクロなどで! 作り込みすぎるのは良くない
  • 32. リリースビルドに含めないように 仕組みが完璧という自信があろうとなかろうと! 確認する手順は必要! ! その確認手順が煩雑になったり分かりづらいと! 結局時間がかかってしまう
  • 33. まとめ ❖ API開発者にスタブ用のデータは作ってもらおう! ❖ スタブはあくまで単体テストのためだったり無駄なコミュ ニケーションの時間を減らすためだって事は周知しよう! ❖ リリースビルドに含めないようにするにはテストTarget を別に作るとか基本的なやり方がシンプルでいいよ