Maybe I have never seen this but shouldn't Unit tests show a TEST_TARGET_NAME
in build settings? I just added a Unit test target to an app that has Obj-C code mixed with Swift and I can't get the Unit test to run correctly. It crashes on run time. I have been looking at the build setting from unit tests to the UI test target that is already there and a few things come to mind. First, the non-existent test target name from build settings under User-Defined is not there and
Bundle Loader
has stuff inputted in it on the Unit test but not the UITest target and for some reason the 'Product Bundle Identifier' on the Unit test is different than on the UI test target. Also, 'Weak References in Manual Retain Release' is set to YES on UI but NO on Unit. Test Host is populated on Unit but not on UITest. Again the UI test target seems to run just fine but it doesn't reference any classes from the app. It literally just runs the UIApplication and does a run through the app. The Unit Test I get one main crash on run-time dealing with a
Thread 1: implicit Objective-C entrypoint +[<class name> UI] is deprecated and will be removed in Swift 4.
I will say I picked up this project and trying to clean a lot of it up but I feel like the previous developers just started upgrading to the latest and greatest versions of Xcode and never really migrating cleanly. Can anyone provide any input on this?
Related
so - I'm new to swift, but done lots of other languages - and I'm big into testing - I rely heavily on my tests to catch stuff - especially structurally.
I keep getting tripped up in Xcode - I hit "run" and it runs.. and I think I'm fine - then down the track I go to add another test, and find my test project doesn't even compile.
How do I make Xcode compile all the projects in the solution when I run any one of them, regardless of what I run. I don't want to be able to run my app, if there's a compile error in my tests... and I don't want to ever explicitly compile the test project. In the perfect world, it would also run all the tests before running the app, so I can't even run the app if I have a test failure.
I have a number of logic unit-tests (where my project files have a target membership of the App and AppTests). I want to add a call to xcodebuild test-without-building to my build system so that my unit-tests run for each build.
However, the tests cannot run on the release build (because release doesn't build for testing).
Is my only choice to build both the release version and the debug version during my build, so that I can use the debug version only to perform the tests? That's very different and very much worse to the other test frameworks I've used (GTest, Catch). Why can't the tests stand on their own?
The test-without-building command is not actually meant to "run the tests without rebuilding the app", but rather it's supposed to be used in tandem with the build-for-testing command.
Please refer to the "Advanced Testing and Continuous Integration" WWDC 2016 session for more info.
The gist is: use build-for-testing to build an .xctestrun file, which is then used by test-without-building to run the tests. This is particularly useful to run big suites across different machines, although I have never done it myself.
Now that we have established that you can't use test-without-building on its own, the only option to run the test from the command line and if they pass build a Release version is to use xcodebuild test, which is going to build the app.
As for the why does it need to be in Debug, I don't have a precise answer. In iOS land, at least in the teams I worked with, the difference between Debug and Release builds is always only on things like the options passed to the compiler in terms of optimization, the architectures to build on, and the type of code signing.
This means that the code that runs in Debug vs Release is exactly the same, and since we already established that you'll need to build the app twice, one to run the tests, one to generate the releasable version, running the tests in Debug seems acceptable.
I'm trying to add some Tests for my application. Following the Document from Apple, I add two testing bundles to my project.
The logic tests are no problem, but when I try to make the application tests on a device I always get the error that the logic tests don't run on a device.
In Xcode 3 there is no problem with that. Only Xcode 4 throws this error...
Any suggestions?
Thanks, Tim
i was also having problems with setting up application tests in xcode4.
A solution that worked for me was as follows:
Assuming you have an application target called "MyApp"
Add a new target of type "other/Cocoa Unit Testing Bundle" to the project e.g "MyAppTesting". Here all Unit test files are located.
Go to MyAppTesting Build Phases and add MyApp as Target Dependency. This assures that MyApp is build before building the MyAppTesting target.
Open the Build Settings of MyAppTesting and change
Bundle Loader: $(BUILT_PRODUCTS_DIR)/MyApp.app/MyApp
Test host: $(BUNDLE_LOADER)
That causes the tests to run within MyApp.
Open the Build Settings of MyApp and change
Symbols Hidden by default: NO (for both)
Strip debug Symbols during Copy: Debug:NO
By doing so you do not have to include every .m-file into the test target.
To run the test on a device plugin the device and select the scheme "MyAppTesting on device" and run as test. Assure that the mentioned scheme has set "Debug" within Test/Build Configuration which should be default.
Best regards.
I've followed the Unit Testing Applications guide from the iPhone Development documentation. I followed all the steps and it worked with the TestCase from the documentation. But as soon as I changed the TestCase to test real Code from my project I ended up with linker errors. All classes that are used in the TestCase are reported as missing.
I've already searched the internet and found that the Bundle Loader property must be set to "$(BUILT_PRODUCTS_DIR)/MyApplication.app/Contents/MacOS/MyApplication". But this also fails because the file could not be found.
Any ideas what I have to do to tell the linker where to search for the missing files?
Make sure that you have added your classes to the unit test target. So if you are creating a unit test for class foo right click on foo.m, select info and then from the Targets tab ensure the checkbox for your unit test target is selected.
I found examples on how to debug your unit test in Cocoa or the ADC page here.
But I can't get the debugging to work for an iPhone app target. I can get the tests up and running and they are run during the build, but what I need is to debug the tests for some of the more complex failures.
You might consider moving your tests to GHUnit, where they run in a normal application target, so debugging is straightforward.
This can be done by setting up a separate Executable for the project that uses the otest tool to run the unit tests, after setting a bunch of relevant environment variables for the executable. I have used this method to successfully debug SenTestKit logic unit tests.
I found the following links helpful:
http://www.grokkingcocoa.com/how_to_debug_iphone_unit_te.html (also contains help to fix common errors encountered setting up the project).
http://cocoawithlove.com/2009/12/sample-iphone-application-with-complete.html (covers both logic tests and application tests)
http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/otest.1.html (Man Page for otest XCode tool)
The NSLog messages show up in Console.app
Should give you a starting point.
In Xcode 4, you can set breakpoints in your unit tests.
Create a new project with "include unit tests" checked.
Put a breakpoint in the failing unit test.
Press Command-U to test.
If you do Build & Go instead of just build, then you can set breakpoints in your unit tests and debug them traditionally. This is if you are using the google toolbox for iphone unit testing; i don't know how you are doing it and if the process is different.