• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
OHHTTPStubsを使ったiOSアプリ開発
 

OHHTTPStubsを使ったiOSアプリ開発

on

  • 3,994 views

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

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

Statistics

Views

Total Views
3,994
Views on SlideShare
817
Embed Views
3,177

Actions

Likes
6
Downloads
2
Comments
0

7 Embeds 3,177

http://blog.koogawa.com 3112
https://twitter.com 59
http://www.slideee.com 2
http://translate.googleusercontent.com 1
http://tweetedtimes.com 1
http://www.google.co.jp 1
http://news.google.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    OHHTTPStubsを使ったiOSアプリ開発 OHHTTPStubsを使ったiOSアプリ開発 Presentation Transcript

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