After upgrading to the 4.1 iOS SDK my unit test bundles always return with the following two errors and one warning:
An internal error occurred when handling command output: -[XCBuildLogCommandInvocationSection setTestsPassedString:]: unrecognized selector sent to instance
An internal error occurred when handling command output: -[XCBuildLogCommandInvocationSectionRecorder endmarker:]: unrecognized selector sent to instance
Run unit tests for architecture 'i386' (GC OFF) did not finish
I get these errors despite it reporting that all X out of X tests passed. I read about a similar bug in an older version of XCode that also occurred immediately after it was released (something about a bug in a regular expression for time) that could be mitigated by setting your time zone to Pacific Time, but I can't say for sure it's a regression to there specifically.
Is anyone else having this problem?
There is a fix available on the apple dev forums,
https://devforums.apple.com/thread/68687
it's a date parsing problem. The fix is quick, it requires including one .m added to your test bundle. The fix is available above or from:
http://gist.github.com/586296
It does seem to be a regression with some part of the reporting code not respecting timezone issues. The output is tagged as ending before it began, so gets very confused and chokes.
One work-around, that I found somewhere on Google, is to change the Run Script stage of the target.
Change
"${SYSTEM_DEVELOPER_DIR}/Tools/RunUnitTests"
to
"${SYSTEM_DEVELOPER_DIR}/Tools/RunUnitTests" 1> /tmp/RunUnitTests.out
It’s working round the issue, rather than solving it, but does work.
This is a confirmed bug in Xcode 3.2.4/4.1 SDK. It has been reported to Apple.
Upgrading to Xcode 3.2.5/4.2 beta SDK solves the problem. I don't know if access to beta SDK:s is open, or if you need to be a registered developer, though.
I'm getting the same issue too.
Oddly enough, I can get the unit tests to complete properly by running them through the debugger as per http://www.grokkingcocoa.com/how_to_debug_iphone_unit_te.html
So it looks like something wrong with the XCode interface to otest...
I really don't want to set my timezone to PST which this post seems to be indicating as I'm in the UK...
Related
I am using Unity as a library for SwiftUI quite a while now. However when updating to the newest iOS version (16.1) it stopped working. Compiling runs without a problem but during runtime I get an error when Unity is starting:
in:
I even started a completely new project with Unity included to SwiftUI and get the same error. As this is some kind of assembler code and I certainly do not know how to read it I don't really know where I have to start searching.
In the console I get: "warning: UnityFramework was compiled with optimization - stepping may behave oddly; variables may not be available." I tried several ways to turn off optimization as described in related questions which did not work. When unchecking "Debug" in the scheme options the project starts normally
A similar thing happened to me. I'm not entirely sure if it's the same problem but in the console, I got a message saying UnityFramework is running optimized and may behave oddly. Unfortunately, I've tried a couple of ways to disable optimization but I've yet to find a solution.
For now, I'm able to bypass this error by disabling the debugger entirely. In order to do this, you have to go to Product -> Scheme -> Edit Scheme and uncheck debug executable.
I'm not sure if this will work for you but I figured it'd be worth a shot!
I've recently started receiving the following error whenever I enter play mode in the Unity editor.
Resolve of invalid GC handle. The handle is from a previous domain.
The resolve operation is skipped. UnityEngine.GUIUtility:ProcessEvent
(int,intptr,bool&)
This occurs every time I enter play mode, I'm not sure what I changed to cause this. The game still builds successfully without errors and I can't seem to find any issue with the game once built. It's worth mentioning that I may have noticed a slight dip in fps since I started getting the error. This is only while in play mode, not in the built player, although I might be imagining it, not sure.
I'm using version 2021.3.10f1, and recently updated from an earlier version, although have been using this version for around 2 weeks without issue.
Can anyone help?
Anyone get iCuke to work with XCode 4?
I'm trying to follow the iCuke tutorial at http://pragprog.com/magazines/2010-07/bdd-on-iphone-icuke
I get a time out error when trying to run the first feature:
Given "QuickContacts.xcodeproj" is loaded in the simulator # iCuke-0.6.3/lib/icuke/cucumber.rb:197
execution expired (Timeout::Error)
/opt/local/lib/ruby/1.8/timeout.rb:64:in `start'
/opt/local/lib/ruby/1.8/net/http.rb:1035:in `request'
features/add_contact.feature:7:in `Given "QuickContacts.xcodeproj" is loaded in the simulator'
I had all kinds of problems getting this (more precisely iCuke in general) to work a few days ago. I'm afraid in the end I abandonded it and went for Frank instead.
That said I had the same problem with Frank but I found a better solution to the problem than fixing the XCode integration (imho). Take a look at this project: I whipped up a cucumber step to boot my binaries in the simulator without the need for crufty Applescripts that convince XCode to do your bidding. Perhaps you can do something similar for iCuke?
For anyone interested...our step looks something like this:
def run_app_in_simulator
target = ENV['TARGET_PATH'] // how you set this is down to you....
if not system('ios-sim', 'launch', target, '--verbose', '--sdk', '4.2', '--exit', '--family', 'ipad')
raise "Unable to launch simulator"
end
end
After tinkering around a little bit in xcode, I was able to get past the timeout issue.
It looks like this can be resolved if "Universal Access" is enabled:
Click on "Xcode -> Preferences->Documentation" , ensure that Universal Access is selected.
I've managed to set up unit tests for my library in Xcode 4. I've performed builds with tests that I know will pass and fail (i.e. STAssertTrue(YES) and STAssertTrue(NO) ) just to make sure it's working. I'm using the default apple SenTest libraries following this document.
However, when my tests are running I'm getting this error in the build log :
An internal error occurred when handling command output: -[IDEActivityLogSectionRecorder endMarker]: unrecognized selector sent to instance 0x20310b580
To be clear, it's not affecting the running of the tests at all, just the output into the build window. All the tests run each time so I can tell a pass / fail by looking to see if the build succeeds or fails.
However, when my tests fail I can't find out which one fails because the output seems to stop when it gets to that error.
Does anyone have experience with unit testing / Xcode 4 / this error?
I just posted this on another thread, but I'm going the opposite direction for Xcode 4.
Please see my blog post exploring the topic, leave a comment if you think I'm wrong.
I realise it doesn't directly answer your question, but forget SenTestingKit and use GHUnit. It'll take you about 10 minutes to figure out (much more straightforward than OCUnit) and will save you a lot of headaches. IMHO, Apple should be shipping it with Xcode instead of OCUnit.
GHUnit can run your tests in a true application environment (with a GUI), or on the command line. It literally just drops into your existing project as a separate target.
https://github.com/gabriel/gh-unit
I have setup UnitTests for some of the logic of my iphone app, I followed apple's guide for UnitTests in XCode, however when some of the assertions fail - instead of highlighting the place directly in code like a regular compilation error - XCode just displays the number of errors in the bottom-right corner and I have to look up the errors in the output log. Does anyone know what additional steps one has to take to make XCode highlight assertion failures in UnitTests like regular errors in code?
This is a known bug in Xcode. I don't think it has worked for at least as long as version 3.2.x but it might have broken earlier. I filed a bug report with Apple back in march but it got closed as a duplicate so they are aware of the problem. I don't imagine it will get fixed in the 3.X incarnation since Xcode 4 is on its way.