Clearly separate Tests from Production Code (improved setup)

[letsdev]

Hi,

I better liked to create a IntegrationTestAppDelegate that inherits from my apps delegate and add looks somewhat like this instead of putting that stuff into my production codes app delegate:

#import "IntegrationTestsAppDelegate.h"
#import "MyTestController.h"

@implementation IntegrationTestsAppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    [super application:application didFinishLaunchingWithOptions:launchOptions];

    [[MyTestController sharedInstance] startTestingWithCompletionBlock:^{
        // Exit after the tests complete so that CI knows we're done
        exit([[MyTestController sharedInstance] failureCount]);
    }]; 

    return YES;
}

@end

Doing it this way has the following advantages:

• Clean separation of the actual apps target and the integration tests target
• No need for the additional Preprocessor Macro RUN_KIF_TESTS

Disadvantages:

• You also need to implement a separate main for the Integration Tests that could look like this:

#import <UIKit/UIKit.h>
#import <Foundation/Foundation.h>
#import "IntegrationTestsAppDelegate.h"

int main(int argc, char *argv[])
{
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([IntegrationTestsAppDelegate class]));
    }
}

I personally like this variant better for the sake of the complete separation between tests and production code.

What do you think?

[implementation]

Wat?

Why do you mention me?!?!?!
Why don't you mention @octodog for example?!

31.01.12 15:03, letsdev пишет:

Hi,

I found it much easier to create a IntegrationTestAppDelegate that inherits from my apps delegate and add something like this:

#import "IntegrationTestsAppDelegate.h"
#import "MyTestController.h"

@implementation IntegrationTestsAppDelegate

• (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
  [super application:application didFinishLaunchingWithOptions:launchOptions];

  [[MyTestController sharedInstance] startTestingWithCompletionBlock:^{
  // Exit after the tests complete so that CI knows we're done
  exit([[MyTestController sharedInstance] failureCount]);
  }];

  return YES;
  }

@EnD

Doing it this way has the following advantages:

• Clean separation of the actual apps target and the integration tests target
• No need for the additional Preprocessor Macro RUN_KIF_TESTS

Disadvantages:

• You also need to implement a separate main for the Integration Tests that could look like this:
  #import<UIKit/UIKit.h>
  #import<Foundation/Foundation.h>
  #import "IntegrationTestsAppDelegate.h"

int main(int argc, char *argv[])
{
@autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([IntegrationTestsAppDelegate class]));
}
}

I clearly like this variant better for the sake of the complete separation between tests and production code.

What do you think?

---

Reply to this email directly or view it on GitHub:
#109

[octodog]

Wat?

31.01.12 15:05, implementation пишет:

Wat?

Why do you mention me?!?!?!
Why don't you mention @octodog for example?!

31.01.12 15:03, letsdev пишет:

Hi,

I found it much easier to create a IntegrationTestAppDelegate that inherits from my apps delegate and add something like this:

#import "IntegrationTestsAppDelegate.h"
#import "MyTestController.h"

@implementation IntegrationTestsAppDelegate

• (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
  [super application:application didFinishLaunchingWithOptions:launchOptions];

  [[MyTestController sharedInstance] startTestingWithCompletionBlock:^{
  // Exit after the tests complete so that CI knows we're done
  exit([[MyTestController sharedInstance] failureCount]);
  }];

  return YES;
  }

@EnD

Doing it this way has the following advantages:

• Clean separation of the actual apps target and the integration tests target
• No need for the additional Preprocessor Macro RUN_KIF_TESTS

Disadvantages:

• You also need to implement a separate main for the Integration Tests that could look like this:
  #import<UIKit/UIKit.h>
  #import<Foundation/Foundation.h>
  #import "IntegrationTestsAppDelegate.h"

int main(int argc, char *argv[])
{
@autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([IntegrationTestsAppDelegate class]));
}
}

I clearly like this variant better for the sake of the complete separation between tests and production code.

What do you think?

---

Reply to this email directly or view it on GitHub:

#109

Reply to this email directly or view it on GitHub:
#109 (comment)

[letsdev]

Wat?! I never intended to mention one of you guys. All the @ things in my post are just source code.

Very nice user name :D So you always get a mail when ANYONE on github posts objective-c code in an issue? Great :D

[octodog]

It was a joke ;)
Use triple backticks to highlight code properly.

Like this

31.01.12 15:27, letsdev пишет:

Wat?! I never mentioned one of you guys. No idea what you're talking bout. All the @ things in my post are just source code.

---

Reply to this email directly or view it on GitHub:
#109 (comment)

[letsdev]

ok: you just get messages if a stupid github noob like me posts objective-c code :)

[bnickel]

That's a clever solution. I can't believe I never saw it before.

Anyway, this issue is out of date due to KIF not using this runner approach anymore. Closing.