Adding dummy objects to project

Question

I want to add dummy objects for testing in project, but I don't want them to be included in my final build. So I have my AppDelegate class and there in imports:

#ifdef TESTING
#import "DummyBeaconLocationManager.h"
#else
#import "BeaconLocationManager.h"
#endif

And later:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
...
#ifdef TESTING
    [[DummyBeaconLocationManager sharedInstance] startRanging];
#else
    self.beaconLocationManager = [BeaconLocationManager sharedInstance];
    [self.beaconLocationManager startRanging];
#endif
    return YES;
}

But the problem is that I have to include this in my Target Membership, not my test target. Is there a way to not include these files in my main target, but only in the Test target?

Edit: Whats need to do is test my app after launch. I want to test it on simulator but app using beacons. So I created dummy objects that represent beacons and simulate location manager. When the app starts with TESTING option it not start ranging beacon but put a dummy objects as a beacon instead.

Keaton

You don't explain why you need the testing object created in your app delegate so I'm not sure if this will help but it might so: qualitycoding.org/app-delegate-for-tests – Balas

Could you make a specific target for your test builds? – Enface

I don't get it - test target still runs AppDelegate methods right? I have a test target but app have to launch somehow – Keaton

What Carl Veazey means is, you can create another target like your app main target which is not the test target. In the project navigator click on your project so you see the screen with the list of project and target on the left and their settings to their right. There ctrl-click on the main target and a popup menu should offer "Duplicate". Do this and you now have a "testing app" target where you can add the files which should not go with the distribution. – Micelle

yea, just create another target for testing, and remove Dummy source from production target – Bountiful

Answer 1

Once you follow these steps, you will be able to add test classes with test functionality to your build. To run your app using the test functionality, you should select the Testing scheme that is configured below.

Xcode Project Configuration (using Xcode 7.0.1)

To allow conditional imports and functionality to be effective for testing, you will need the following ingredients:

1. Testing Configuration
2. Testing Target
3. Testing Scheme

Short Explanation of Schemes, Targets and Build Configurations

• Schemes point to targets and configurations.
• Targets can be configured with different build settings.
• Configurations can be added, to branch out target build settings.

Here are the steps:

1. Duplicate a Configuration for testing

With the project file selected in the Project Navigator, follow these steps:

1. Select the project target
2. Select Info
3. Select + to add a configuration

4. Select Duplicate "Debug" Configuration

5. Rename the new configuration, and drag it to re-order

2. Duplicate a Target for testing

Now that you have a testing configuration, add a testing target. With the project file select in the project navigator, follow these steps:

1. Right-click or Option-click an existing target, and select Duplicate.

2. Tap on the new target to rename it, then drag it to reorder your targets.

3. Manage Schemes

Now that you have a testing target and configuration, you are ready to add a scheme that points to the new target and configuration.

1. Tap on the schemes (next to the stop button), and select Manage Schemes...

2. In the Schemes manager popup, if you have elected to autocreate schemes, the new scheme will already be listed. Otherwise, you can tap + in the popup to add a scheme. Each scheme can be shared, as shown here:

3. Tap on the new scheme to rename it, and drag it to reorder:

4. To edit the new scheme, ensure that it is selected, and tap Edit...

5. In the edit panel, select the Testing build configuration

6. Ensure that the scheme points to the Testing Target, by tapping on the Executable drop-down:

7. Ensure the scheme is pointing to the correct build configuration, for other actions, such as Automated Testing:

4. Configure the build settings for your targets

Now that you have your testing scheme set up to point to the Testing configuration, it will behave exactly like the Debug configuration, until you modify the build settings. Follow these steps, to change build settings for your Testing configuration:

1. For most build settings, there is an option for each configuration. When choosing which configuration to use in your settings, ensure the main target is selected:

2. The Preprocessor Macros are under the section titled 'Apple LLVM 7.0 - Preprocessing':

3. Tap on a row, to select it, tap the enter key to edit and commit your changes, use the arrow keys to move up or down. It is a good practice to define all your preprocessor macros for all configurations, like this:

5. Add a class to your Testing target

Now, the Testing Scheme points to a configuration that behaves differently from your Debug configuration. You should now be able to select the Testing scheme from the schemes dropdown menu, and run your Testing configuration.

You can modify the target membership of a class in one of two ways.

1. When you create a new file, the third panel where you can choose the location, has options at the bottom, for each target:

2. When you select a file in your Project Navigator, the File Inspector has a Target Membership panel where you can make modifications:

Schemes

Schemes are usually paired to build configurations. One good practice is to have a scheme/configuration for each audience that needs a different version of your build. Here are some basic audiences that typically need separate configurations:

• Developer > DEBUG
• Developer > TESTING
• Internal Testing > DEVELOPMENT
• Beta Testers / Production > APP STORE

Subclassing

If you want to modify any functionality in testing mode, you could use a subclass, and only add the subclass to your testing target.

Delegacy

Answer 2

Alright, if I got it right, you should:

• a) Create a separate target for testing porposes (as @Carl Veazey and @Rainer Schwarze suggest) with almost the same code base as your main target.
• b) I would recommend mocking your location manager and beacon
  objects via subclassing from BeaconLocationManager and YourBeacon
  (for example). Then, you just override the real behavior with your
  simulator-specific actions.

At the end of the day, your testing target will only contain 2 more classes (mock beacon manager and mock beacon) comparing to the main target. No additional changes on the project structure or code semantics reuired. Good luck.

Irizarry

Answer 3

I could vary easily be wrong on this, but I am guessing this might work:

Like when using cocoapods, when you create the pod file you deselect the target (Project Name). What if you do that, then select the target (Project NameTests)

Compendious

If it's not include in main target you cannot use it in main target, ergo you cannot define behaviour different for test target and main target – Keaton

@Kuba. Okay, that makes sense. I thought there had to be something wrong with it. – Compendious