Ad-Hoc builds distributed over the air (OTA)

It is possible to share your test Ad-Hoc builds over the air, so testers won’t need to downlod ipa files and sync them via iTunes. Sometimes testers are having their iOS devices...

It is possible to share your test Ad-Hoc builds over the air, so testers won’t need to downlod ipa files and sync them via iTunes. Sometimes testers are having their iOS devices synced with computers not on their desks so it would be nice to download a version of the without a need to connect the device to the iTunes.

How to do that? It’s quite simple. Do normal steps to archive your app, and while you be generating new ipa file (on the save sheet) select “Save for Enterprise Distribution” at the bottom of the screen.

You need to type to informations there. First – the full path to the place on the network your file will be stored at, second – application name.

Generating OTA build

And voila! You’ll get to files – ipa itself and special plist file. What to do with that?

Put it on the webserver together with a HTML file like this

<html>
<body>
<p>Click <a 
href="itms-services://?action=download-manifest&url=
http://testingserver.com/1.0/myapp.plist">HERE</a> 
to install My App version 1.0 Beta</p>
</body>
</html>

Now, when the user will open the given page and click the link, safari on the device will understand that given link is acutallu an itunes action to install the application which manifest (the plist file you’ve generated) is linked under url attribute.

Simple, isn’t it?

Unit test results

Sometimes (according to Google – never ) one have a need to gather all results from unit tests. In example – to send them through the network. Why? Imagine that you...

Sometimes (according to Google – never :P ) one have a need to gather all results from unit tests. In example – to send them through the network. Why? Imagine that you need to report every unit test results to corporate server. Just to check for regressions… or something. I need it so my students can check “The Board” during the challenge.

Unluckily OCUnit given in XCode4 doesn’t seem to allow us to gather this kind of information. There is a solution though.

SenTestCase doesn’t have any methods that can return the results. What’s more – it is created and prepared for each test separately. That’s unfortunate.

The entry method that is called for each test is -(void)performTest:(SenTestRun *)aRun; That give’s us a hint when the test is actually triggered. But we still don’t know which one and how many of them are still left. But we can count the number of runs… information about the number of test methods in the class we can get from Class itself.

So we simply add following method to our test case:

- (void)performTest:(SenTestRun *) aRun
{
    static int performed = 0;
    static int failed = 0;
    static int totalTestCount = 0;
 
    if (totalTestCount == 0)
    {
        totalTestCount = [[[self class] testInvocations] count];
    }
 
    [super performTest:aRun];
    performed++;
    if ([aRun failureCount])
        failed++;
 
    if (performed == totalTestCount)
    {
        NSLog(@"Total tests %u failed %u", performed, failed);
    }
}