I have a GHUnit test target, TestGH, which I'd like to use to test classes in my application, TestApp. I'm using Xcode 4.5 and trying to run TestGH on iPad 6.0 Simulator.
I believe I've configured the TestGH build correctly in the Build Settings and Build Phases. I've set the Target Dependencies to "TestApp" I've added the *.m files for the classes I'd like to test--along with the test case classes which will test them--to the Compile Sources section TestGH.
Other notable configuration:
In the app target, TestApp:
Symbols Hidden By Default: No
Product Name: TestApp
In the test target, TestGH:
Bundle Loader: $(BUILT_PRODUCTS_DIR)/TestApp.app/TestApp
Mach-O Type: Bundle
Other linker flags: -ObjC, -all_load
Product name: TestGH
Test Host: $(BUNDLE_LOADER)
I suppose I have this mostly right, as I discovered these settings by fighting through compile/link errors, reading stackoverflow, and blogs.
However, when I launch TestGH, the Log Navigator shows:
error: failed to attach to process ID 2305 (2305 corresponds to 'sh' according to activity monitor, fyi)
Simulator screen remains black, and Xcode shows "Attaching to TestGH" in the status.
Any ideas?
I've gone through many suggested fixes/workarounds I've seen discussed here related to "failed to attach to process."
Deleted DerivedData folder in Library/Developer/Xcode, deleted everything under Library/Application Support/iPhone Simulator. Tried all the options under Product->Edit Scheme for the TestGH target--tried Debugger = GDB, LLDB, None, Launch = Automatically, wait. Results are always the same.
Related
I recently turned on stricter warnings for a project, and Xcode started throwing warnings on some of Apple's classes. I'm not sure if this is an Apple bug, or if I'm doing something wrong. I'm using Xcode 6.1.1 on Yosemite.
TL;DR: adding some strict warning flags to your project starts throwing warnings in various XC*Test*.h headers. The issue is intermittent, but the steps below have reproduced the issue on multiple computers.
Steps to reproduce:
Create a new Xcode project via File → New → Project.
Choose iOS → Application → Single View Application.
For Product Name, type MyApp. Choose Objective-C and Universal. Save the project.
Build the project with CommandB. Run the tests with CommandU. Observe that they both finish with no errors or warnings.
Click on the Project to go to the Project Settings.
Click on the blue MyApp Project (as opposed to MyApp or MyAppTests targets).
Click on the Build Settings tab.
Search for Other Warning Flags.
Enter the following string for the Other Warning Flags for the app:
-Weverything -Wno-objc-missing-property-synthesis -Wno-objc-property-synthesis -Wno-direct-ivar-access -Wno-assign-enum -Wno-float-equal -Wno-sign-compare -Wno-switch-enum -Wno-gnu -Wnewline-eof
Build the app again. You should see three or four warnings about treating #import as #import, which is expected given the warnings you just enabled.
Clean the project with CommandShiftK
Build again. You may see extra warnings. If not, then you need to…
Delete the DerivedData folder, at least for this project. It is located at /Library/Developer/Xcode/DerivedData/MyApp-*, where * is some random identifier string. You may also need to delete /Library/Developer/Xcode/DerivedData/ModuleCache.
Clean and build again. And again. It may take a few times. Eventually...
You will see code and documentation warnings on XCAbstractTest.h, XCTestCase.h, and XCTestSuite.h. Screenshot:
As you can see, these warnings would be quite valid on my own code, but this is Apple’s framework code. Is there any way to stop these weirdly intermittent warnings from appearing? Or is it an Apple bug that the file gets warnings at all? I’m leaning Apple bug, because plenty of other Apple headers use #import instead of #import, and none of them is throwing warnings.
Update: I filed a radar: http://www.openradar.me/20038246
Update 2: I was able to glean some more information that may be helpful:
The issue appears to be at least partly related to where Derived Data is stored. See this screen recording, courtesy of Sam Marshall for details: http://cl.samdmarshall.com/a4Hy
Note that, when I reproduce the same steps as in Sam's video on my computer, I am not able to get rid of the extra warnings. They always come back. Possible differences between my and Sam's setups:
Sam is on Xcode 6.1, while I am on 6.1.1.
Sam is on Mavericks, while I am on Yosemite (10.10.2).
When I build in Xcode 6.3b2, I get an additional warning about "building module 'UIKit'". See screenshot: http://cl.ly/a3sK
Update 4: Radar was closed as a duplicate of an issue.
Update 5: I have a workaround, which is to disable the problem warnings on the Tests target only. Here’s a partial diff. Xcode won’t add the $(inherited) automatically, so you’ll have to add it yourself.
+ WARNING_CFLAGS = (
+ "$(inherited)",
+ "-Wno-documentation-unknown-command",
+ "-Wno-auto-import",
+ "-Wno-incomplete-module",
+ );
I want to create logic tests for my library and run them on iOS device. I know that we can only run them on simulator. But I have seen that I can run the default test on iOS device. Here is the setup.
Create new iOS 7.0 app (single view application, nothing fancy) using xcode 5.
This will create default test which fails with message failed - No implementation for "-[MyAppTests testExample] when you try to run it.
I am able to run this test both on simulator and device using xcode with same output.
Does that mean I can run XCTests on device also?
Also when I try to run the same test using command line it gives me error saying the scheme is not testable. The how come Xcode is able to run it? Here is the command line that I execute to run on device.
xcodebuild test -scheme MyApp -configuration Debug -destination name=TestIPhone
and am seeing following message
2014-03-14 16:04:12.423 xcodebuild[620:1207] [MT] DVTAssertions: Warning in /SourceCache/IDEFoundation/IDEFoundation-3582/Framework/Classes/Model/Execution/RunContext/IDEScheme.m:1290
Details: Scheme <IDEScheme:0x7ff6abc8d2b0:'MyAppTests'> was asked to test, but it is not testable and shouldn't have allowed this action.
Object: <IDEScheme: 0x7ff6abc8d2b0>
Method: -testOperationWithExecutionContext:buildIfNeeded:onlyBuild:destination:overridingProperties:overridingTestingSpecifiers:buildLog:overridingBuildConfiguration:restorePersistedBuildResults:invocationRecord:name:title:error:actionCallbackBlock:
Thread: <NSThread: 0x7ff6abc0e5d0>{name = (null), num = 1}
Please file a bug at http://bugreport.apple.com with this warning message and any useful information you can provide.
xcodebuild: error: Failed to build project MyAppTests with scheme MyAppTests.
Reason: Scheme "MyAppTests" is not testable.
Any insight would be helpful. I am confused.
This issue has been resolved with Xcode5.1 update.
When I run my tests in XCode 5, the main window of my OS X app appears on the screen for a couple of seconds while running the tests. Why? Even if I uncomment all my tests it still opens my main window.
You are running application test, not logic test. This means an instance of your app will be started and then run the unit tests. This allow you to perform some integration test that require your app is running.
Here is the guide to setup application test and logic test.
If you want to change it to logic test (so it run faster and don't need to start your app first):
go to build settings for your unit test target
search Bundle
remove Bundle Loader and Test Host
Thats right, you have to delete the "Bundle Loader" and "Test Host" from your build settings.
But you have to add the necessary implementation files to your unit test target. The necessary files are what you want to use in your unit test cases. You need to do this because in logic tests XCode wont compile the whole application. So some of your files will be missing.
This is en error message if you have left out a file:
Undefined symbols for architecture i386:
"_OBJC_CLASS_$_Module", referenced from:
objc-class-ref in Lobic Network.o
objc-class-ref in Logic_Unit.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
You can add the missing files by selecting the implementation file and bringing up the file inspector. There will be a section named "Target Membership" and there you can set the files target membership to your unit test also.
With XCTest, application files DO NOT need to be included within XCTest targets. The XCTest bundle is linked against the application which makes those files available during runtime.
To make this work, ensure the compiler option "Symbols hidden by default" is set to NO Within the Application target.
Here is a blog post with screenshots for clarity:
http://zmcartor.github.io/code/2014/02/24/slim-xctest-targets
The advantage of this approach is test target builds much much faster.
In XCode 7, removing Host Application does not work for me. Indeed I use the following to avoid app runs.
Setup Test Scheme Arguments
in main.m
static bool isRunningTests()
{
NSDictionary* environment = [[NSProcessInfo processInfo] environment];
NSString* testEnabled = environment[#"TEST_ENABLED"];
return [testEnabled isEqualToString:#"YES"];
}
modify main()
int main(int argc, char * argv[]) {
#autoreleasepool {
if (isRunningTests()) {
return UIApplicationMain(argc, argv, nil, nil);
} else {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
}
If the tests are for code that can run on desktop and mobile, you can run them without a simulator or hosting them within your app.
The trouble is that you cannot use the scheme chooser for your normal target (desktop or iOS) to run the test.
The following worked for me in Xcode6.
File > New Target...
Select Cocoa Testing Bundle from the OS X category.
Take care to select None from the target drop-down.
Click Finish. Add the relevant files to the new target as described above.
Now create a scheme to run the test.
Click the schemes chooser top-right and choose New Scheme..., click the drop-down and navigate down the list to the new target. Now you can choose the scheme from the schemes chooser, and use ⌘U to run the tests.
I just wasted a morning on this.
Project was created in XCode 4 and used SenTesting.
Tried migrating tests on XCode 5/XCTTest
Had same issue - app ran in simulator and test never started
after trying everything (change from app to logic tests, change to XCTest, remove SenTesting)
gave up created a clean XCode 5 project.
Added all my files in and tests ran ok.
May still have issues with Storyboard as these were built with XCode 4.
Drastic but it works so keep it as last resort.
On XCode5, the app does start. This answer shows how to change its delegate when running unit tests so that it exits right away: https://stackoverflow.com/a/20588035/239408
I'm getting the below error message and multiple XIB compilations failing with exit code 6. I can't make much sense of it. Anyone know what might be wrong?
I've cleaned the project, but that didn't help.
The errors only happen when archiving, not when simply running the app. EDIT: Scratch that, after I did the build (and clean), running no longer works.
CompileXIB MyProject/en.lproj/MainMenu.xib
cd /Users/wesley/XCode/MyProject
setenv XCODE_DEVELOPER_USR_PATH /Applications/Xcode.app/Contents/Developer/usr/bin/..
/Applications/Xcode.app/Contents/Developer/usr/bin/ibtool --errors --warnings --notices --output-format human-readable-text --compile /Users/wesley/Library/Developer/Xcode/DerivedData/MyProject-ciandcogabqifsfgbscfrfgabfet/Build/Intermediates/ArchiveIntermediates/MyProject/InstallationBuildProductsLocation/Applications/MyProject.app/Contents/Resources/en.lproj/MainMenu.nib /Users/wesley/XCode/MyProject/MyProject/en.lproj/MainMenu.xib --sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk
2013-04-09 09:48:22.377 ibtoold[77454:1207] [MT] DVTAssertions: ASSERTION FAILURE in /SourceCache/IDEInterfaceBuilder/IDEInterfaceBuilder-3084/ibtool/IBToolErrorForwarder.m:32Details: Unhandled error: 13Object: <IBToolErrorForwarder: 0x401036100>Method: -initThread: <NSThread: 0x40030a1e0>{name = (null), num = 1}Hints: NoneBacktrace: 0 0x000000010c04c7c3 -[DVTAssertionHandler handleFailureInMethod:object:fileName:lineNumber:messageFormat:arguments:] (in DVTFoundatio 1 0x000000010c04c5f4 _DVTAssertionFailureHandler (in DVTFoundatio 2 0x000000010b571bba (in ibtool 3 0x000000010b569115 (in ibtool 4 0x000000010b563f74 (in ibtool 5 0x00000000000000Command /Applications/Xcode.app/Contents/Developer/usr/bin/ibtool failed with exit code 6
ASSERTION FAILURE CAUSES :-It could be the file you are opening or corrupted preferences. Try deleting preferences or opening a known good nib/xib file.
Also
Deleting everything in your "Derived Data" folder
Clean your project.
More similar question xcode won't compile iOS apps, crashes when .xib or .storyboard files are opened helps you!
Also Try
removing all *.xcdatamodel directories that are not displayed in XCode from your *.xcdatamodeld directory. These directories appear after *.xcdatamodel renaming in XCode.
I'm trying to update my iPad app on the App Store. I filled out the "new version" form on iTunes Connect and then tried to upload the new version with Application Loader. It rejected the .zip file giving me three errors.
I had changed the "Bundle Version" line in the Info.plist file to 1.1, and added "Bundle versions string, short" (also 1.1). Then I build the .app file, and zipped it up with the .mobileprovision file.
The zip file: Chordpad.zip
Contains: ChordPad.app, ChordPad_Distribution.mobileprovision
These are the errors Application Loader is giving me:
1. iPad: application executable contains unsupported architecture(s): i386
2. Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate.
3. Unable to extract codesigning entitlements from your application. Please make sure ChordPad.app is a valid Mach executable that's properly codesigned.
As far as I know, all my certificates are valid. Could anyone please help me fix this?
If the i386 architecture is being used, you are probably building for the simulator. Switch to device to get the arm architectures.