2015-09-28 3 views
8

OHHTTPStubsのようなツールを使用してXcode 7の自動UIテストでHTTPリクエストを傍受し、スタブ/モックしようとしましたが、運はありません。ここでXcode 7の自動UIテストでHTTPリクエストをスタブすることは可能ですか?

は、私はUIテストファイルのセットアップ方法にOHHTTPStubsを使用して、任意のHTTPリクエストを捕獲しようとしているかの例です:

override func setUp() { 
    super.setUp() 

    let matcher: OHHTTPStubsTestBlock = { (request) -> Bool in 
    return true 
    } 

    OHHTTPStubs.stubRequestsPassingTest(matcher) { (response) -> OHHTTPStubsResponse! in 
    return OHHTTPStubsResponse.init() 
    } 
} 

UIがこれを防ぐ働きをテストする方法について何かがありますか?誰でもこれを達成できましたか?

+0

はねえ、あなたは解決策で終わるのですか? – MatterGoal

+0

はい、下記に追加しました。 – dtrenz

+0

SBTUITestTunnelを使用して動的にHTTPリクエストをスタブするには、私の答えを確認してください。[こちら](http://stackoverflow.com/a/36909859/574449) –

答えて

8

Martijnは正確に指摘したように、UIテストの仕組みのため、実行時に直接アプリケーションと対話することはできません。XCUITestCaseNSUserDefaultsなどのHTTPのモックや操作はアプリには影響しません。

あなたが本当にHTTPまたは特定のUIテストのためのセットアップ&ティアダウンアプリの環境を模擬できるようにする必要がある場合は、起動引数を設定したり、XCUITestCasesetUp()方法でアプリを起動する前に、環境変数を起動する必要がありますし、その後、起動コードや環境変数を読み込んでテスト環境をブートストラップするようにアプリケーションコードを修正してください。

例テストケース

class MyTestCase: XCTestCase { 

    /** 
    Called before each test in this test case. 
    */ 
    override func setUp() { 
    super.setUp() 

     let app = XCUIApplication() 
     app.launchArguments = [ "STUB_HTTP_ENDPOINTS" ] 
     app.launch() 
    } 

} 

例AppDelegate

func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool { 

#if DEBUG 
    if (NSProcessInfo.processInfo().arguments.contains("STUB_HTTP_ENDPOINTS")) { 
    // setup HTTP stubs for tests 
    } 
#endif 

    return true 
} 

注:この例では、スタブ・コードおよび任意のJSONにOHHTTPStubsようなフレームワークをモックHTTPを使用するために使用する必要のあるフィクスチャは、すべてテスト対象ではなくアプリターゲットにある必要があります。

これは、トピックを読んで非常に便利なスレッドである:https://github.com/AliSoftware/OHHTTPStubs/issues/124

+0

これは本当にあなたがスタブを達成することができますが、あなたはまた、スタブ "コード"とそれの中にスタブされたネットワークファイルでアプリを出荷されるように思えます。これはおそらく非常に悪いことです。 – Daniel

+0

私はスタブコードをDEBUGプリプロセッサマクロのifチェックでラップするので、スタブコードは実際にそれをApp Storeビルドに入れるべきではありません。これを示すためにコードサンプルを更新しました。これを指摘してくれてありがとう。 – dtrenz

3

UIテストは、アプリケーションとは別のインスタンスで実行されています。アプリケーションのクラスは利用可能かもしれませんが、単なるコピーに過ぎません。

あなたがここで提供ソリューションでUIテストモードで実行している場合は、検出することができ、あなたのアプリケーションで

How to detect if iOS app is running in UI Testing mode

私は個人的にはオリジナルのポストで述べたlaunchEnvironment溶液で行きました。 「あなたは重複を嫌う場合

func realm() -> Realm { 
    let dic = NSProcessInfo.processInfo().environment 
    if dic["TEST"] != nil { 
     return try! Realm(configuration: Realm.Configuration(inMemoryIdentifier: "test")) 
    } 
    return try! Realm() 
} 

が、あなた:

override func setUp() { 
    super.setUp() 

    let app = XCUIApplication() 
    app.launchEnvironment["TEST"] = "1" 
    app.launch() 
} 

そして(RealmManagerと呼ばれる)私のシングルトンinstantiatorsの1(レルムデータベースをインスタンス化するための)次のようになります。私のセットアップは、このようになります。とにかく既にXCUIApplication().launch()を複製している場合は、いつでもXCTestCaseまで拡張したカスタムテストケースクラスを作成し、そこにsetUpをオーバーライドして、それをすべてのテストクラスで使用することができます。

+0

異なるテストケースはどうやって実行しますか?例として、ログイン成功とログイン失敗をテストしたい場合、ベストプラクティスは2つの異なる応答をスタブすることです...あなたのロジックでこれをどう扱うのですか?私は "app realm"または "test realm"で動作しているかどうかしか分かりませんが、私は別の "test realm"レスポンスを扱うことはできません。 – MatterGoal

+0

偽のユーザーですか? "user" + "wrongpassword" =失敗、 "user" + "password" =成功。 –

関連する問題