I need to add test cases to an existing project, so I tried adding a new test target via
File -> New -> Target -> Cocoa Touch Testing Bundle
From the test navigator filter bar.
Even after adding, the target is not getting listed in the test filter bar.
May be because of this issue, Product -> Test option is diabled in my project.
Also I could see some differnce between the build setting in my project and another sample project I started in Xcode 6.1 in which Product -> Test option is enabled and everything working fine for Test cases.
Please find the build settings screen shots.
Any help is appreciated.
I had this exact problem. It turns out my existing project was creating my Cocoa Touch Testing Bundle with the .app extension when it should've been a .xctest extension.
You can fix this by going to your test target you created. Build Settings > Wrapper Extension and changing it from app to xctest.
You may have to restart Xcode after this change to select your test target.
UPDATE: I found out the reason the Testing Bundle was becoming a .app extension in the first place. I had to go to the main project Wrapper Extension and make sure it was blank instead of .app. Apparently that was forcing all targets to become .app extension as well.
Related
I created the first unit test target in our iOS application by simply clicking through the plus icon inside the test tab on the left navigator.
(The target to be tested is set to the main application)
The unit test target created itself successfully but when I try to run the pre-generated tests, it outputs an error message. The error message displays that the build input file cannot be found. More specifically, the file /Plugins/XXXTests.xctest/XXXTests cannot be found. I double checked and in fact that file is not in that directory.
While I could not find anything similar to this problem, I tried everything that was close to it but nothing seemed to fix problem.
Any help would be greatly appreciated!
For me, it was because the test source files are not included in the test target.
Including those test files in the test target solved it.
It's been a while but we finally found a solution! The problem was in the Podfile where our pods weren't being applied to the different targets of our app. To fix the solution we had to define a shared pod module that included all of our pods and then we applied this new module to each different targets in our app.
Our Podfile looks like this now
I hope this helps out some people!
Do you have it set properly in schemes?
Go to Product -> Scheme -> Edit Scheme -> Test and check, if your test target is properly added to the correct scheme. It should look something like this:
Every time I start to run my app, or I'm just starting Xcode I get this error:
I think the problem is that I don't know where my .xctest files are. I think I maybe deleted them.
Would be very nice if someone of you could help me! Maybe tell me how to recover these files, make some new one or something else.
You accidentally added one of your Xcode Unit Test files to your main app target.
Remove it:
Select test file
Open right side panel
Select Identity and Type tab
Unselect your app Target (not the unit test lego icon)
Tip:
Next time you add a new unit test, only add it to your unit test target. If you accidentally include any of your app targets, they will not have the XCTest framework available.
See also Apple Technical Q&A QA1954 'Cannot load underlying module for XCTest' which covers several variants of the issue
https://developer.apple.com/library/archive/qa/qa1954/_index.html
The main project does not link with the XCUnit framework. You should create a separate testing target for your project, if one does not already exist, and add your test source files to that target.
Select your project in the Project Navigator. This will open the project's settings in the editor.
Click the "+" button at the bottom of the column listing your Targets.
If you are working on an iOS project template, select iOS > Test > iOS Unit Testing Bundle.
If you are working on an OS X project template, select OS X > Test > OS X Unit Testing Bundle.
Does anyone know how to perform unit testing on app extension target, especially keyboard extension target?
What have I tried (in the unit test target):
In the "General" tap, set it's target to the extension target instead of the container app.
Set the "Bundle Loader" to the path of the binary of the extension target, which looks like $(BUILT_PRODUCTS_DIR)/com.mycompany.keyboard.appex/com.mycompany.keyboard
Set the "Test Host" to $(BUNDLE_LOADER).
In the "Build Phases" tap, set the "Target Dependencies" to both the container app and the extension.
After these things done, I can build it successfully but always get "Test Failed" with an log Test target SogouInputTests encountered an error (Test session exited(1). without checking in. If you believe this error represents a bug, please attach the log file at /tmp/TestStatus-UXfvxw.log).
I'm using Xcode 6 beta 3.
I have reported the bug to Apple. And sadly, the answer is that the keyboard extension is not support unit test now. The answer comes from Apple:
It's not currently supported to run unit tests inside an app extension
Instead, factor the code you want to test into a framework and test the code there
Link the framework into your extension
Just ran into similar issues trying to unit test an extension. Independently did exactly the same thing the author tried with Bundle Loader pointing to .appx path with no success of course.
I really did not like the idea of creating a separate framework just for testing so I ended up of adding testable source into the extension test target. It is really simple if you don't have too many source files in your extension:
Select you extension test target in Project settings
Go to Build Phases
Expand Compile Sources
Click +
Add source files with your testable code.
Build for Testing
Why it works:
Once you add extension sources into your extension test target, XCode is going to double reference each of them and compile in both the normal extension build and the test build thus eliminating linking issues.
Are there any drawbacks?
You will have to manually synchronize the source file list in the extension test target. Whenever you add/remove files in the extension target, you may need to do the same in its test target.
What I did which was easier than the other suggestions (no framework creation, no weird settings on build settings, phases, etc) was adding the file that I wanted to test (from the extension target) into the Target Membership of the test target:
The only "drawback" would be that your test target will also include files from your extension (rather than using #testable import like with the main app), but since you are not shipping your test target I would say there is no drawback :)
Tested on Xcode 10.
Note: Only works with Swift code, with ObjC due the BridgingHeader is not possible to follow this approach.
I am wondering if you can link one Unit Testing bundle to multiple targets. So one can test all the application targets with one Testing bundle.
I have some shared code between all app targets but also some specific calculations based upon which app target is running.
Currently I have to set the Bundle Loader option in the Build Settings to the used application target's .app file if I want to test a different application target.
My question to you all is : can this be done without creating multiple test bundle targets for every app target, and without always changing the Bundle Loader option?
You need to:
Select the target you want to test
Go to Test navigation tab
Right-click on test target you want to enable
Click on Enable [name_of_your_target]
No, at this point you can't. It's like the extensions, you have to create a new one for each project's targets you have.
It's not pretty usefull but if the code differes from one to another target, the tests can fail because of missing code, not failing code.
It's why it's not allowed.
Sorry for the negative answer.
I have an XCode workspace with a user interface project (UI) and a core logic project (Core). I want OCUnit unit tests in the UI project, so I have added a new target for testing, as is commonly done.
I am able to run tests just fine until I put in import statements for classes in the main UI target which in turn reference the Core project.
The error I get is "Lexical or Preprocessor Issue 'xxx.h' file not found". I do not get this message when I build the main UI target directly.
It's as if the main UI target knows about Core when it is built, but when it is referenced from the test target it seems to know nothing about Core.
I took the step of adding a reference to the core project using the "Link Binaries with Libraries" The item in the list remains red. A clue? Maybe, but the red reference in the Link list doesn't keep the UI target from building and using core classes. I also made the main target a dependency of the test target.
Make sure you check out the Apple sample code "Unit Tests":
https://developer.apple.com/library/ios/#samplecode/UnitTests/Introduction/Intro.html#//apple_ref/doc/uid/DTS40011742
Make sure your library project is set as a Dependancy in your OCUnit test target's build phases, AND it's linked as a library.
Open up your project in Xcode. In the File menu, go to Project Settings... (or Workspace Settings... if you are using a workspace). Click Advanced... and make sure Unique is checked. Clean and rebuild.
Check your BUILD_PRODUCTS_DIR to see if the headers for your library show up in there. If they don't, first check the build phases in your library target to make sure the headers you need are in the Public section (the Project section may work as well, but try Public and see if that solves your issue).
That covers the most common problems people seem to run into in your situation. When in doubt, check the target settings in the UnitTests sample against yours. Good luck!
In addition to Jon Reid's answer, I had to do the following as well:
In your test target, go to Build Settings. Set "Always Search User Paths" to YES
In your test target, go to Build Settings. Add the path to your static library headers to Header Search Paths.