I have a simple weather app which gets data from OpenWeather API. I wanted to add UI tests to project. I added some classes to AppNameTests target in Target Memberships and after that I got many error in that class. But test is working and project build correctly and run without any problem. Is somebody know how to resolve this problem?
EDIT:
Your app's source code files should not be members of the unit test and UI test targets. To access your app's classes, structs, and functions in your tests, use the #testable import statement in your test classes.
#testable import AppName
Regarding Xcode showing a bunch of error messages when the project builds and the tests run without error, you can clean your build folder by choosing Product > Clean Build Folder, and see if that makes the error messages go away.
Related
My iOS app uses Realm. It has Realm subclasses like MyRealmClass.
When I try to run any unit test in my workspace, I get the following error:
"RLMObject subclasses with the same name cannot be included twice in the same target. Please make sure 'MyRealmClass' is only linked once to your current target."
What I tried:
* I tried removing 'MyRealmClass' from the Test target. That does not work. When I do that the code won't compile anymore because the code is dependent on 'MyRealmClass'
I have a growing swift project that I have been writing both unit and UI tests for along the way. My UI tests run just fine, but my unit tests have stopped compiling. I am using "#testable import X", but anytime I try to access a class from the project, even if I make that class public, I get a "Use of unresolved identifier" error. I have no idea what I could have changed to cause things to start failing.
Choose "Clean" from the Xcode "Product" menu and then recompile. That will often get it working again. For some reason, we have to "Clean" before the classes are made available to the test target.
My original answer below outlines the old solution before #testable was available to us.
--
Make sure the source file for PostCell is included in the list of source files for the tests target.
You can do this by going to the tests target and adding it to the list of "Compile Sources":
Or by clicking on "Target Membership" to the "File Inspector" for the source in question:
I have recently integrated XCTest into my project. It works fine when I run test cases using the play button in source editor or Using the play button in test navigator. My problem is, when I use the Test Button (The Spanner like symbol) in the ToolBar I am getting compilation errors.I already have integrated pods in my project and there is a static library created by me as well.
Note : During thorough checking I figure out all the compilation errors coming in the static library created by myself.The error count is too large so compiler shows "too much error" message
Is there any additional setup needed for including the static library into tests?
This issue arise only in case of testing I can succesfuly build and run the project
Thanks
Test Succeeded Here
Compilation Error Here
Try doing a clean build to see if xcode hasn't cached anything when you try to do a full test.
Got the solution finally, the issue is because of test target added as part of my custom library. When I try to run the test from toolbar xcode try to run all the unit test targets (My main project's test and my custom library's test case ). Library's test case can't run independently because it has some coupling with main project. Remove the test target and run test cases everything perfect.
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 have a custom Framework I use within my normal App target as well as the corresponding UnitTest target. Turns out that confuses the runtime in such way that it is unable to choose the correct implementation since it has multiple choices:
objc[35580]: Class AClass is implemented in both ../MyApp.app/MyApp and ../MyApp.app/MyAppTests. One of the two will be used. Which one is undefined.
That of course leads to weird behavior if you try to check an object's class hierarchy or do any other class related checks.
So it boils down to the following two questions:
I don't see similar logs for e.g. UIKit components, but this framework is also linked to both targets. Have I incorrectly compiled the framework?
Is it just a trivial configuration issue I missed?
PS: I already checked similar posts like 1 or 2, but although everything is configured as described, the problem remains.
You have added the dependency framework to the Tests target. This is flawed thinking. Since your primary application ALSO exports the SAME framework you will receive warnings about duplicated symbols for any classes found in the framework.
By removing your framework from the test target you can resolve the warnings. Remember, you're not losing any functionality by not linking against the same framework in the test target. Trust me, your code is still there.
I ran into a similar problem here: Xcode5: creating new testing target
The key is to create a new unit testing bundle, point it to your original target, and then don't do anything else! If you start including frameworks and source files into the test target, it'll generate these linking errors. The test target is supposed to "inject" the test classes into the actual target, not create a new separate target on it's own. So you just need to import the header files in your test class, and write your test cases.
I think the bundle should only "read" the framework's header files but not build the sources and leave that task to the App (remove the Framework .m files from the UnitTest target).
Right now the App and the UnitTest are both building the Framework, thus the duplicated classes.