Problems when declaring stubs in app and in tests about ohhttpstubs

[AliSoftware]

Hi @pbernery

This issue was already encountered by someone else and is a tricky case when you mix Application Tests and Unit Tests. See issue #47 for more details where we finally understood what was going on.

I was planning on writing a dedicated wiki article to explain this tricky case in details, but haven't got the time to publish it yet.

In summary, the problem is that when you run Application Tests, Xcode will launch your application in the simulator (and calling you UIApplication and its delegate's methods, like application:didFinishLaunchingWithOptions: and all), and then will load the test bundle as a "plugin" (dynamically loaded bundle) inside your application.
As a result, there are two different bundles loaded in memory with executable code (which is a pattern that can be encountered in OSX development when you develop plugins but are normally never encountered in iOS as iOS apps are forbidden to dynamically load executable code — that's maybe why it's not familiar to you — … except that Xcode use this OSX mechanism to execute iOS Application Tests).

The consequence it that the OHHTTPStubs class that you use in your "Application Bundle" code (like when you use it to stub your unimplemented Web Services) and the OHHTTPStubs class that you use in your "Tests Bundle" code are not the same classes in memory as they are the same class but duplicated in two different bundles. And thus have separated installed stubs (stubs installed in the class loaded by the Application Bundle are not shared with stubs installed in the class loaded by the Tests Bundle).

Actually, that's generally what you expect, as stubs installed by your Unit Tests should only affect Unit Tests itselves, and stubs installed by your application should only affect your application code and not your test code too. This is all because Xcode loads the application bundle first and the test bundle then separately, as two separate executable bundles.

---

If you don't do any Application Tests (like GUI testing) but only do Unit Tests (like functional tests to test your WebServices and all) that don't need your Application and its UI to be running:

• Select your Project on the File Navigator,
• then select your Unit Tests target
• Then in the "General" tab of this test target, choose "None" in the "Target" dropdown that appears to avoid your application bundle to be launched before your Unit Tests bundle.

This way your UIApplication won't be launched, its delegate methods won't be called, and you will only have the Unit Test bundle and only one OHHTTPStubs class. Of course, as a result, as they won't be loaded by the app bundle anymore when running your tests, you will need to add all the classes you want to test (like your WebServices classes) to your Xcode's UnitTest target in order to address & test them.

[pbernery]

Wow, thank you @AliSoftware for this comprehensive answer! :)

That's what I had in mind but wanted to be sure before continuing. Unfortunately, my project cannot have his tests executed in "Unit Tests" mode. It uses a library (closed, I don't have the source) that asserts on some things that I guess come with the initialization of an app. I may find a workaround for this issue though.

Anyway, thank you again. I guess I can close this issue.

[AliSoftware]

Hi there

Just to let you know I finally written/updated the dedicated wiki article about this issue (at last!)

My opinion is that you should simply not link OHHTTPStubs with your test target as it is already linked against your app target and this latter will load/host the test target ultimately. This will prevent the OHHTTPStubs lib to be loaded twice and would avoid such issues. This is also true for any other library linked against both your app and test target when you are doing application tests.

[samirGuerdah]

👍