Introduction

This is a quick tutorial on doing iPhone unit testing using the facilities in the Google Toolbox For Mac. Please send mail to the group if any clarification is required.

Basic Project Setup

Hopefully your project already has an application target for building something for the iPhone.

1. Create a new iPhone Target of type “Cocoa Touch Application” via “Project Menu > New Target…”. Choose a name that makes some sense such as “Unit Test”. Be sure to use a “Cocoa Touch Application” target as opposed to a “Cocoa Application” target or a “Cocoa Touch Static Library” target or “Cocoa Touch Unit Test Bundle”.
2. Add google-toolbox-for-mac/UnitTesting/GTMIPhoneUnitTestMain.m to your target
3. Add google-toolbox-for-mac/UnitTesting/GTMIPhoneUnitTestDelegate.m to your target
4. Add google-toolbox-for-mac/UnitTesting/GTMIPhoneUnitTestDelegate.h to your project
5. Add google-toolbox-for-mac/UnitTesting/GTMSenTestCase.m to your target
6. Add google-toolbox-for-mac/UnitTesting/GTMSenTestCase.h to your project
7. Add google-toolbox-for-mac/UnitTesting/GTMUnitTestDevLog.m to your target
8. Add google-toolbox-for-mac/UnitTesting/GTMUnitTestDevLog.h to your project
9. Add google-toolbox-for-mac/Foundation/GTMObjC2Runtime.m to your target
10. Add google-toolbox-for-mac/Foundation/GTMObjC2Runtime.h to your project
11. Add google-toolbox-for-mac/Foundation/GTMRegex.m to your target
12. Add google-toolbox-for-mac/Foundation/GTMRegex.h to your project
13. Add google-toolbox-for-mac/GTMDefines.h to your project
14. Add a new ‘run script’ build phase as the last step of your target build via “Project Menu > New Build Phase > New Run Script Build Phase”, and dragging it to the end of the build steps if needed.
15. Edit your Run Script Build Phase by double clicking it, and set the shell to “/bin/sh” and the script to"PATH_TO_GTM/UnitTesting/RunIPhoneUnitTest.sh", where PATH_TO_GTM is the path to your local version of google-toolbox-for-mac.
16. Xcode’s new application stationery generates an Info.plist that specifies a Main nib file base name. Open the new unit test’s .plist file and remove that line. If you don’t do this, RunIPhoneUnitTest.sh will crash when UIApplication throws an exception trying to load an inappropriate or non-existent nib file.
17. Build! Note that if you choose build and go you will see your unit tests executed twice, once as part of the build script, and once being run

Your target should now build cleanly, and if you check the build log you should see something like: “Executed 0 tests, with 0 failures (0 unexpected) in 0.001 (0.001) seconds” at the end.

Trouble Shooting

• Make sure you are not linked against the SenTestingKit.framework.

Creating a unit test

1. Add the source you want to test to your target. For example if you want to test class Foo, make sure to add Foo.h and Foo.m to your target.
2. Add a new unit test file to your target via “File > New File” and choose “Objective-C test case class” from the “Mac OS X” Cocoa category. Call it FooTest.m, or follow whatever convention your project has for naming test classes.
3. In FooTest.h, change #import <SenTestingKit/SenTestingKit.h> to #import "GTMSenTestCase.h"
4. Also set up your class so that it inherits from GTMTestCase (not GTMSenTestCase) instead of SenTestCase
   @interface MyTestCase : GTMTestCase { ... }
5. Add test cases as you normally would. See Apple’s Documentation for a good tutorial on how to test in Objective C. The key is that your test case methods are declared - (void)testBar. The name must start with “test” and they must return nothing and have no arguments.

Now when you build your target you should now see test cases executing. You can repeat this process creating additional source files for each class you want to write Unittests for.

Debugging

You can debug your unit test executable the exact same way you would unit test any executable. You shouldn’t have to set up anything. Note that you may see cases where the unit test build fails, but it doesn’t fail when you are debugging. When the unit test build is running several flags are turned on to encourage failures such as MallocScribble, NSAutoreleaseFreedObjectCheckEnabled etc. You may want to look inRunIPhoneUnitTest.sh and see what is being enabled for you.

Notes

• We find that having a .h for tests to be mostly useless, and tend to just the interfaces for the tests in with the implementation so I only have one file to worry about.
• Make sure to check out the extra ST macros that we have added in GTMSenTestCase.h that go above and beyond the set included with the default OCUnit.
• STAssertNoErr(a1, description, …), STAssertErr(a1, a2, description, …)
• STAssertNotNULL(a1, description, …), STAssertNULL(a1, description, …)
• STAssertNotEquals(a1, a2, description, …), STAssertNotEqualObjects(a1, a2, desc, …)
• STAssertEqualObjects(a1, a2, description, …), STAssertEquals(a1, a2, description, …), STAssertEqualsWithAccuracy(a1, a2, accuracy, description, …)
• STAssertOperation(a1, a2, op, description, …), STAssertGreaterThan(a1, a2, description, …), STAssertLessThan(a1, a2, description, …), STAssertLessThanOrEqual(a1, a2, description, …)
• STAssertEqualStrings(a1, a2, description, …), STAssertNotEqualStrings(a1, a2, description, …), STAssertEqualCStrings(a1, a2, description, …), STAssertNotEqualCStrings(a1, a2, description, …)
• STAssertTrueNoThrow(expr, description, …), STAssertFalseNoThrow(expr, description, …), STAssertThrows(expr, description, …), STAssertThrowsSpecific(expr, specificException, description, …), STAssertThrowsSpecificNamed(expr, specificException, aName, description, …), STAssertNoThrow(expr, description, …), STAssertNoThrowSpecific(expr, specificException, description, …), STAssertNoThrowSpecificNamed(expr, specificException, aName, description, …)
• You can’t run the build script while the iPhone simulator is running. The build script does attempt to kill it off before it runs, but if you seeCouldn't register PurpleSystemEventPort with the bootstrap server. Error: unknown error code. This generally means that another instance of this process was already running or is hung in the debugger. or Abort trap "$TARGET_BUILD_DIR/$EXECUTABLE_PAT" -RegisterForSystemEvents you probably need to figure out why the simulator (or another iPhone process) is already running. The exact error has changed with different versions of the iPhone SDK.

Advanced Stuff

Unit test Logging

When Unittesting is done correctly, you often have a lot of log messages logging because you are testing edge cases that you may not expect to hit in the real world very often. It’s nice to be able to verify that the log messages you are receiving as you run your tests are the ones that you expect to receive. You can do this in GTM by enabling unit test logging.

1. Assuming you are using _GTMDevLog to do your logging,#define _GTMDevLog _GTMUnittestDevLog somewhere, either in target settings, or in your prefix. If you are using NSLog you can just define it to be _GTMUnittestDevLog.
2. Add google-toolbox-for-mac/DebugUtils/GTMDevLog.m to your target.
3. Add google-toolbox-for-mac/UnitTesting/GTMUnitTestDevLog.m to your target.
4. Add google-toolbox-for-mac/Foundation/GTMRegex.m to your target.
5. You may also need to add some headers depending on your search paths

Now when you build all of the logging that you do via your unit tests will get checked to make sure that it conforms with your expectations. You set up these expectations before running your tests using [GTMUnitTestDevLog expect*] methods. See GTMUnitTestDevLog.h for more info.

UI and State Testing

GTM can also help you test your UI’s representation and state.

1. Add google-toolbox-for-mac/UnitTesting/GTMNSObject+UnitTesting.m to your target.
2. Add google-toolbox-for-mac/UnitTesting/GTMUIKit+UnitTesting.m to your target.
3. Add google-toolbox-for-mac/UnitTesting/GTMCALayer+UnitTesting.m to your target.
4. Add google-toolbox-for-mac/Foundation/GTMSystemVersion.m to your target.
5. Add the CoreGraphics and QuartzCore frameworks to your target.
6. You may also need to add some headers depending on your search paths

Check out UnitTesting/GTMUIKit+UnitTestingTest.m for examples of using UIUnitTesting on the iPhone.

For more information on some of this, check out CodeVerificationAndUnitTesting. Hope this helps.

Unit Test Environment Variables

To encourage “bad behavior” by the code being tested, the RunIPhoneUnitTest.sh script sets a variety of environment variables. If you are wondering why the unit tests fail when you are building, but don’t fail when you are running, it may be because of a side effect of one of these variables. Take a look at all the export commands within RunIPhoneUnitTest.sh to see what’s actually going on.

Leaks

By default the iPhone unit tests will run leaks after all the tests have completed. This can be turned off by setting the GTM_DISABLE_LEAKSenvironment variable before you execute the RunIPhoneUnitTest.sh script. Out of the box, NSZombies will also be enabled. This however interferes slightly with leaks and makes it difficult to get good backtraces and context. If you want the backtraces and context, set theGTM_DISABLE_ZOMBIES environment variable before you execute the RunIPhoneUnitTest.sh script. All leaks will appear as warnings on the build console.

Termination

Some of Apple’s tools (such as Instruments) don’t want the app to terminate underneath them. By default the iPhone unit test app will terminate when it has finished it’s run. Set the GTM_DISABLE_TERMINATION environment variable if you want to disable termination and just have the unit test “run” until you are done with it.

Keychain Testing

If your code uses the keychain, you may need to set GTM_DISABLE_IPHONE_LAUNCH_DAEMONS=0 before you run your unit tests. See RunIPhoneUnitTest.sh for details on this flag and why it should be set.

It’s a good idea to test your application using VoiceOver, because it allows you to experience the application in the same way that VoiceOver users will experience it. Using VoiceOver to run your application can expose problem areas, for example, confusing labels, unhelpful hints, and unreachable elements, that make your application less accessible.

VoiceOver is a sophisticated application that provides many powerful features to users with disabilities. For example, VoiceOver users can use an invisible dial, known as the rotor control, to change the results of some gestures on the fly. Although you don’t need to become an expert VoiceOver user to test your application with it, you do need to know a handful of basic gestures. This section describes how to activate VoiceOver and use it to run your application. (To learn more about using VoiceOver, seeiPhone User Guide, available at Apple – Support – Manuals.)

First, go to Settings > General > Accessibility > VoiceOver and tap the switch control to turn VoiceOver on. If you provide hints for any accessible elements in your application, check to make sure the Speak Hints switch is on (it is on by default). Before leaving VoiceOver settings, make sure the Speaking Rate slider is adjusted to an appropriate value.

After you’ve turned VoiceOver on, you’ll notice that many familiar gestures have different effects. For example, a single tap causes VoiceOver to speak the selected item and a double tap activates the selected item. There are also a couple of new gestures you should learn to make testing your application with VoiceOver easier. The gestures you’re most likely to need for testing are listed below:

• Drag over the screen. Select and speak each item as you touch it.
• Tap. Speak the selected item.
• Two-finger tap. Stop speaking the current item.
• Flick right or left. Select the next or previous item.
• Double tap. Activate the selected item.
• Two-finger flick up. Read all accessible items from the top of the screen.
• Two-finger flick down. Read all accessible items from the current position.

There are also a few tasks you might need to perform. For example:

• Enter text on the keyboard. Flick left or right to select the desired key, then double-tap to enter the character. Alternatively, you can drag your finger over the keyboard until the desired key is selected. Then, while holding the selected key with one finger, tap the screen with another finger to enter the character.Flick up or down to move the insertion point forward or backward in the text.
• Scroll a list or area of the screen. Flick up or down with three fingers.
• Adjust a slider. Flick up or down (with a single finger) to increase or decrease the setting.
• Unlock iPhone. Select the Unlock switch, then double-tap the screen.

When an element is selected, VoiceOver draws a black rectangle around it (similar to the shaded rectangle Accessibility Inspector draws), which is called the VoiceOver cursor. While you’re testing your application you can use the VoiceOver cursor as another way to make sure elements are being selected as you expect.

To simulate the experience a visually impaired user might have with your application, you can run it with the VoiceOver Screen Curtain in place. When you activate the Screen Curtain, VoiceOver turns the device display off. Testing with the display turned off obliges you to rely on the information VoiceOver speaks and removes the temptation to use your application as a sighted user would. To turn off the display while you use VoiceOver, triple-tap the screen with three fingers. To turn the display back on, perform the same gesture again.

• Works within Apple’s guidelines and rules for ad hoc provisioning and device # limitations
• Free over-the-air beta distribution. Apps are installed in one tap over-the-air and users will be notified of future builds.
• Easily and elegantly send as many builds and updates to your beta devices Distribution Lists: Easily select who gets what when you distribute
• Recruitment: Promote your beta app and select new users that sign up

What TestFlight Doesn’t Do

• You don’t need to jailbreak or alter your phone; theydon’t alter the device.
• It is not a replacement for Apple’s ad hoc provisioning profile and device # limitations.

more about testappflight visit http://testappflight.com

Before you decide how to present your product to iPhone OS users, you need to understand the range of options you have. Depending on the implementation details of your proposed product and its intended audience, some types of software may be better suited to your needs than others.

This section divides software for iPhone OS–based devices into three broad categories, primarily based on implementation method. Roughly speaking, you can create:

■ An iPhone application, which is an application you develop using the iPhone SDK to run natively on iPhone OS–based devices.

■ Web-only content, including web applications, which are websites that behave like built-in iPhone applications.

■ A hybrid application, which is an iPhone application that provides access to web content primarily through a web-content viewing area, but includes some iPhone OS user interface elements.

iPhone Applications

iPhone applications resemble the built-in applications on iPhone OS–based devices in that they reside on the device itself and take advantage of features of the iPhone OS environment. Users install iPhone applications on their devices and use them just as they use built-in applications, such as Stocks, Maps, Calculator, and Mail.

An iPhone application is quick to launch and easy to use. Whether the application enables a task like sending email or provides entertainment to users, it is characterized by responsiveness, simplicity, and a beautiful, streamlined user interface.

Web-only Content

You have a few different options when it comes to providing web-only content to iPhone OS users:

■ Web applications

as web applications, because they behave similarly to the built-in iPhone OS applications. A web application, like all web-only content, runs in Safari on iPhone; users do not install it on their devices, instead they go to the web application’s URL.

■ Optimized webpages

Webpages that are optimized for Safari on iPhone display and operate as designed (with the exception of any elements that rely on unsupported technologies, such as plug-ins, Flash, and Java). In addition, an optimized webpage correctly scales content for the device screen and is often designed to detect when it is being viewed on iPhone OS–based devices, so that it can adjust the content it provides accordingly.

■ Compatible webpages

Webpages that are compatible with Safari on iPhone display and operate as designed (with the exception of any elements that rely on unsupported technologies, such as plug-ins, Flash, and Java). A compatible webpage does not tend to take extra steps to optimize the viewing experience on iPhone OS–based devices, but the device usually displays the page successfully. If you have an existing website or web application, first ensure that it works well on iPhone OS–based devices.

Also, you should consider creating a custom icon users can put on their Home screens using the Web Clip feature. In effect, this allows users to keep on their Home Screens a bookmark to your website that looks like a native application icon. To learn more about creating a custom icon and how to make web content look great on iPhone OS–based devices, see iPhone Human Interface Guidelines for Web Applications.

Hybrid Applications

With iPhone OS, you can create an application that combines features of native applications and webpagesA hybrid application is a native iPhone application that provides most of its structure and functionality through a web viewing area, but also tends to contain standard iPhone OS user interface elements.

A hybrid application gives users access to web content with an element called a web view Precisely how you use a web view in your application is up to you, but it’s important to avoid giving users the impression that your application is merely a mini web browser. A hybrid application should behave and appear like a native iPhone application; it should not draw attention to the fact that it depends upon web sources.

Adding testers to your team

Adding Testers to Your Team

To add an iPhone OS user to your team as a tester:

1. Obtain the tester’s device ID.

   The easiest way to obtain this information is through email. Have your tester follow the instructions for sending their device ID to developers in “Sending Your Device ID to a Developer.”

2. Add the tester’s device ID to the Program Portal.
3. Generate the tester’s provisioning profile in the Program Portal.

   You must select a development certificate, application ID, and only the tester’s device name.

   Figure 9-2 Generic iTunes artwork for test applications

   

The iTunes artwork your testers see should be your application’s icon. This artwork must be a 512 x 512 JPEG or PNG file named iTunesArtwork. Note that the file must not have an extension.

After generating the file of your application’s icon, follow these steps to add it to your application:

1. Open your project in Xcode.
2. In the Groups & Files list, select the Resources group.
3. Choose Project > Add to Project, navigate to your iTunesArtwork file, and click Add.
4. In the dialog that appears, select the ”Copy items” option and click Add.

Distributing Your Application to Testers

Before sending your application to a tester build it using the Release build configuration. You can find the directory containing your binary (and its corresponding dSYM file) by choosing Reveal in Finder from the application in the Products group in the Groups & Files list.

Remember to keep the binary and its corresponding dSYM file on your file system (copy them to a directory that contains a subdirectory for each build you’ve released to your teammates or to testers) so that they’re indexed by Spotlight. Saving both files allows you to symbolize (add symbol information) crash logs testers send you. See“Importing Tester Crash Logs” for more information.

Send your application binary and the tester’s provisioning profile to the tester. One way of accomplishing this task is by compressing these items and emailing them to the tester:

1. In the Finder, select the two files and choose File > Compress.
2. Name the archive <application_name> for <user_name>.zip. For example, MyTestApp for Anna Haro.zip.
3. In the Finder, select the archive and choose Finder > Services > Mail > Send File.
4. In the body of the message make sure to include your application’s target iPhone OS release. If the tester’s iPhone OS version is earlier than the one for which your application was built, they will not be able to install the application on their device.

When a tester receives the items, she or he follows the instructions in “Instructions for Application Testers” to install the application and the provisioning profile.

Importing Tester Crash Logs

To add tester crash logs to the Organizer to view their symbol information, drag the crash logs to the Crash Logs group under the iPhone Development section.

Important: For Xcode to symbolize crash logs (to add information about the API used to the crash log), Spotlight must be indexing the volume in which you store your binaries and their corresponding dSYM files.

Instructions for Application Testers

This section provides instructions to testers about the procedures to follow to test your iPhone applications on their devices. An application tester is a potential user of your application who wants to test it before it’s released through the App Store.

You may send these instructions, along with any special tasks needed to test your application, to customers interested in testing your application.

Sending Your Device ID to a Developer

Before a developer can send you an application for testing, they must register your device with Apple under their application-testing program.

To send your device ID to a developer for test-program registration:

1. Launch iTunes.
2. Connect your device to your computer.
3. Select the device in the Devices list.
4. In the Summary pane, click the Serial Number label. It changes to Identifier.
5. Choose Edit > Copy.
6. Email your device identifier to the developer. Be sure to include your name and device name in the email.
   

   Installing an Application for Testing

   After being successfully registered in a developer’s testing program, the developer sends you an archive containing two files: the application and a provisioning profile. You need to install both files into iTunes to run the application on your device.

   After opening the archive:

   1. Drag the provisioning profile (the file with the .mobileprovision extension) to the iTunes Library group.
   2. Drag the application (the file with the .app extension) to the iTunes Library group.

      The application appears in the Applications list.

   3. Sync your device.

      If the version of iPhone OS on your device is earlier than the test application can run on, you need to update your device with the current release of iPhone OS.

   Sending Crash Reports to a Developer

   When the application you’re testing crashes, iPhone OS creates a record of that event. The next time you connect your device to iTunes, iTunes downloads those records (known as crash logs) to your computer. To help get the problem fixed, you should send crash logs of the application you’re testing to its developer.

   Sending Crash Reports from Macs

   To send crash logs to developers:

   1. In the Finder, open a new window.
   2. Choose Go > Go to Folder.
   3. Enter ~/Library/Logs/CrashReporter/MobileDevice.
   4. Open the folder named after your device’s name.
   5. Select the crash logs named after the application you’re testing.
   6. Choose Finder > Services > Mail > Send File.
   7. In the New Message window, enter the developer’s email address in the To field and <application_name> crash logs from <your_name> (for example,MyTestApp crash logs from Anna Haro) in the Subject field.
   8. Choose Message > Send.
   9. In the Finder, you may delete the crash logs you sent to avoid sending duplicate reports later.
      

      C:\Users\<user_name>\AppData\Roaming\Apple computer\Logs\CrashReporter/MobileDevice

FoneMonkey has been donated to the iPhone developer community by Gorilla Logic, an enterprise application consulting firm that provides complete design, development, testing, and project management services for creating mobile, web, and desktop applications. In addition to mobile applications, Gorilla Logic specializes in developing rich internet applications with Adobe Flex and AJAX-component frameworks, and in devloping complex back-end services with Java.

360logica is exploring opourtunity to use FoneMonkey to automate Iphone and Ipad applications. This will boost our automation in Mobile domain.

for more details Please write aman@360logica.com

• Event handling
  • Touch events
  • Notifications
• File System knowledge
  • Internal file structure
• Mobile-commerce
  • Pay Pal
• Audio/Video streaming
  • MJPEG video streaming
• Location Based Services
  • Google Maps
  • Google Map APIs based on Java Script
  • Core Location Framework
• SyncML
  • Contacts
• Reusable components
  • User Interface
  • Network
• Rich User Interface
  • Native controls
  • Customized controls
  • Screen transition effects