I'm currently using GHUnit and OCMock for testing my app. I'm using them because I like the fact that I can run test code on the actual device.
The way my app is currently designed is that I have some central services and objects available through properties on the app delegate. For example, I've centralised some core data functionality which can be accessed by [UIApplication sharedApplication].coreData.
The problem I've encountered is that in order to run unit tests on the device or simulator, GHUnit uses it's own app delegate which doesn't have these properties. So if a unit triggers code which wants to access them, it fails.
So I'm looking at the design of the app and wondering if I should redesign the way these core facilities are made available. How do you guys design your apps?
One thing I'm considering is extracting this functionality out to a separate object so that I can then use OCMock to simulate it for testing purposes.
Any thoughts?
After thinking about this a while I realised there was a simpler solution. I created a category with the app delegate's interface which applies to the GU Unit app delegate used when running the tests. This way I can get the tests to run and use this category to return OC Mocks when necessary.
And another technique. This time I extended the GH Unit test iPhone app delegate and added the methods and properties I needed. I then modified the main class to call that instead of the original.
Ahhh, so many ways to achieve the same result :-)
Related
I have a custom iOS framework written in Swift that presents AVCaptureVideoPreviewLayer and also presents some custom popup screens. I want to add unit tests and wondering if I can do this without having a host App specified and instead programmatically create a minimal host app.
Some resources I've found that seem to be moving in the direction but were not written with unit testing frameworks in-mind:
https://marcosantadev.com/fake-appdelegate-unit-testing-swift/
https://qualitycoding.org/ios-app-delegate-testing/
It sounds like you want to some test interactions with UIKit, so you'll need a host application. Just make a new empty app as one of your targets, and use it.
Can this be done programmatically? No. The alternative (worth trying at first) is to forego certain kinds of tests. See how far you can get before you add a host app.
Is there any way in Xcode to see which functions get called in sequence, from start to end? (For example: the main function calls the an app delegate method, and so on.)
Can you do this using breakpoints, or is there another way to achieve this?
Use instrument for that. You can access it from Xcode by asking Xcode to run your application using instrument.
or you can type bt in xCode console
If running in the iPhone Simulator, you can use a custom instrument build with DTrace for doing just that. I provide the code and setup steps for building such an instrument in an article on MacResearch here, or you can just download the custom instrument template here.
This particular template will list, in order of execution, every method called on every class from the launch of your application until it is ready to take user input.
Unfortunately, DTrace does not yet work on the iOS devices, so you can't run a custom instrument like this against your application running there.
(Update 10/4/2011) I propose what is probably a better way of handling this in this answer to a similar question, which uses breakpoints instead of DTrace.
I've worked on several iPhone applications which all require some subset of the same services: RemoteIO audio, GPS, push notifications, face sensor activation, idle timeout disabling, etc, etc. The application delegate callback methods become bloated with all of this initialization code which is slightly different in each app.
So my question is: is there a library for handling all this? Some system that lets me say, "this app uses services A, B, and C, and they should launch in this order"? The services would be defined so that they'll automatically get the application lifecycle callbacks they need, like the application going into the background, audio interruptions, etc.
This is pretty ill-defined, which is why I'm hesitant to write this code yet. If someone else has solved the problem then I can avoid duplicating all of the mistakes they made on their approach to a solution.
The only one i could think of would be three20, but not sure if that isn't a bit too much. ( check http://api.three20.info/annotated.php)
Basically I'm trying to find a solution to my issue with sharing an object. I've had a look at SpringBoard's implementation and it looks as if SpringBoard is providing a framework which can be used to retrieve SBDisplay objects (which are basically CALayers).
I know this specific issue is related to iPhones, but I also know that this is also used by a lot of Cocoa software. Could someone point out a way to copy such behaviour?
App 1 (Application launcher) :
Launches client applications
Has the main CALayer object
Serves as the window server
App 2 (Client app) :
Needs the main CALayer from App1 to render itself onto
And again, just to reiterate - I am fully aware of AppStore policies. And yes, I am using a jailbroken device.
I was wondering if anyone knew how iSimulate automatically registers/hooks itself into a debugged iDevice application? It's as simple as including the static library (and a couple of frameworks) and it just works. There are no methods or functions to call. How is this possible?
Short answer: using categories in Objective-C, you can extend or augment any class in the system, including core classes and NSObject itself. (Similar to "monkey patching" in Ruby for example.)
The actual communication is most likely a broadcast, sending packages that don't expect to get an answer back. When you start your app, it just starts intercepting these packages. So it's the simulator app that hooks into the iSimulate stream, rather than iSimulate somehow "reaching into" your app.
Have a look at the open source accelerometer simulator project. You could easily extend it to broadcast touches too, and basically duplicate what iSimulate does. And you learn about the nifty side of Objective-C.