Is there a way to provide a small test window without performing a complete build in Xcode? I know that eclipse gives you a small preview window at the bottom of the IDE but I can not figure it out for Xcode. I am mainly looking to test certain conditions and outputs that may not always print a value to the screen. Any suggestions?
Move your testable code into a framework that is accompanied by its own unit test bundle. Now testing involves just clicking the little run button next to a unit test. You can run a single test method or a whole suite, depending on your needs. When you run a test, the entire app does not need to be built — just the framework; and the app itself never runs and the Simulator never opens. And the results appear in the little Xcode Console pane at the bottom of the project window (and are preserved also in the Report navigator).
This is an excellent way to organize your app structure. I routinely use this kind of architecture.
Related
I have an issue where when I run my application in debug mode, the application shows obvious runtime lags. As specified in numerous articles, the application bundle will run up to 10X faster than when running from xcode (including with instruments).
However, when I open the app (going through the project explorer/products/app_name.app) and show in finder then run the app, several features that work perfectly in debug mode (in my case, certain keyboard press functions).
The app runs much faster as expected than the debug mode runtime, but lacks some of the behaviors which work in debug mode. Furthermore, some other actions close the application altogether.
I don't know where to start figuring this out but have some intuition and would like confirmation what it might be:
1-Instruments: is there a difference of memory usage between debug and application bundle for which debug keeps a cap on memory usage, CPU usage etc?
2- COnsidering cache misses, is it possible that my nSResponder when I activate a key does not catch some later down the track switch cases, which will create a cache miss? (I doubt this since my controls file runs as an extension to one of my main loops). Note: If this works fine in debug mode, why would it not work in the application itself?
Any pointer to why this behavior greatly appreciated, so that I don't make large changes that won't affect the outcome (It's a large project).
So are you saying that when you compile for debugging (-ONone), then things work. But when you compile for release then some things don't work?
Try unchecking 'Enable backtrace recording' in the Options tab of the Run scheme action.
I'm using xcode 4.5 and trying to add logic tests to the project. (This is actually a test, newly created project without unit tests). I'm following this guide:
http://developer.apple.com/library/mac/#documentation/developertools/Conceptual/UnitTesting/02-Setting_Up_Unit_Tests_in_a_Project/setting_up.html
So, what i've done so far:
Created a new project (View Based Application template)
Click on File -> New- CocoaTouchUnitTestBundle
That's it. The tests (as documentation states) are ready to use.
But I have the following problems:
The SenTestinKit.framework appears in red
If I press Test button issue navigator shows nothing:
If I select another debugger here(LLDB by default, trying to select GDB):
Xcode just hangs out:
P.S I also tried to remove SenTestingKit.framework (which is in red) and add new. Nothing changed.
What am I doing wrong ?? I suppose to see something like this(screenshot from apple guide):
Any help will be greatly appriciated!
Actually, your code works now.
I don't know why Xcode didn't initially add the SenTestingKit framework in correctly when you created the test bundle.
But now the code, "testExample" which was auto-generated for you, is running, and it is telling you to add in some real tests, by giving you an error. That's what STFail does.
So, if you take out that line, and start writing your own tests, you should be fine.
If we click on Java perspective in Eclipse and right click on a Java project, we see “new” a JUnit file.On executing the test cases in JUnit we see red/green bar displaying failure/success of test cases.
I am trying to find a plugin that would add these two features :
In the perl perspective (provided by EPIC) , right-click on a Perl
project should list a new “t” file.
On executing perl unit the status of test cases should be displayed
using Reed/Green bar.
If there is no plugin is there a way we can do the same.
As far as I know, there is no EPIC plugin for this or even a more generic TAP-based test runner for Eclipse. Such a thing would be nice to have.
Rigging some sort of report on test success from a web page is pretty common. This can be done using a tool like Test::Harness which can be used to run your test or tests and return or output a report of how well your test run went.
From there, it's a matter of turning that into a red/green progress bar.
If you want to see the progress updated continuously during the test run, you'll have to run and parse the test files more directly as they run. All Perl tests output TAP format, which is a standard format with specs available here:
http://testanything.org
NOTE: Unit testing is a lot easier to setup nowadays. This tutorial is not really relevant for Xcode version 5 and above.
It took me quite some time but I finally managed to make it work for my project.
To create the "logic" tests I followed Apple guidelines on creating logic tests.
This works fine once you understand that the logic tests are run during build.
To be able to debug those tests it is required to create a custom executable that will call those tests. The article by Sean Miceli on the Grokking Cocoa blog provides all the information to do this. Following it however did not yield immediate success and needed some tweaking.
I will go over the main steps presented in Sean's tutorial providing some "for dummies" outline which took me some time to figure out:
Setup a target that contains the unit tests but DOES NOT run them
Setup the otest executable to run the tests
Setup the otest environment variables so that otest can find your unit tests
The following was performed with XCode 3.2.5
Note for XCode 4
In XCode 4 it is possible to debug your unit tests DIRECTLY. Just write your test, add it to your target as one of the tests and set a breakpoint in it. That's all. More will come.
Step 1 - Setting up the target
Duplicate your unit tests target located under your project Targets. This will also create a duplicate of your unit tests product (.octest file). In the figure below "LogicTest" is the original target.
Rename both the unit tests target and the unit tests product (.octest file) to the same name. In the figure below "LogicTestsDebug" is the duplicate target.
Delete the RunScript phase of the new target
The name of both can be anything but I would avoid spaces.
Step 2 - Setting up otest
The most important point here is to get the correct otest, i.e. the one for your current iOS and not the default Mac version. This is well described in Sean's tutorial. Here are a few more details which helped me setting things right:
Go Project->New Custom Executable. This will pop open a window prompting you to enter an Executable Name and an Executable Path.
Type anything you wish for the name.
Copy paste the path to your iOS otest executable. In my case this was /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.2.sdk/Developer/usr/bin/otest
Press enter. This will bring you to the configuration page of your executable.
The only thing to change at this point is to select "Path Type: Relative to current SDK". Do not type in the path, this was done at step 3.
Step 3 - Setting up the otest arguments and environment variables
The otest arguments are straightforward to setup... But this proved to be my biggest problem. I initially had named my logic test target "LogicTests Debug". With this name and "LogicTests Debug.octest" (with quotes) as argument to otest I kept having otest terminating with exit code 1 and NEVER stopping into my code...
The solution: no space in your target name!
The arguments to otest are:
-SenTest Self (or All or a test name - type man otest in terminal to get the list)
{LogicTestsDebug}.octest - Where {LogicTestsDebug} needs to be replaced by your logic test bundle name.
Here is the list of environment variables for copy/pasting:
DYLD_ROOT_PATH: $SDKROOT
DYLD_FRAMEWORK_PATH: "${BUILD_PRODUCTS_DIR}: ${SDK_ROOT}:${DYLD_FRAMEWORK_PATH}"
IPHONE_SIMULATOR_ROOT: $SDKROOT
CFFIXED_USER_HOME: "${HOME}/Library/Application Support/iPhone Simulator/User"
DYLD_LIBRARY_PATH: ${BUILD_PRODUCTS_DIR}:${DYLD_LIBRARY_PATH}
DYLD_NEW_LOCAL_SHARED_REGIONS: YES
DYLD_NO_FIX_PREBINDING: YES
Note that I also tried the DYLD_FORCE_FLAT_NAMESPACE but this simply made otest crash.
Step 4 - Running your otest executable
To run your otest executable and start debugging your tests you need to:
Set your active target to your unit test target (LogicTestsDebug in my case)
Set your active executable to your otest executable
You can build and run your executable and debug your tests with breakpoints.
As a side note if you are having problems running your otest executable it can be related to:
Faulty path. I had lots of problem initially because I was pointing to the mac otest. I kept crashing on launch with termination code 6.
Faulty arguments. Until I removed the space from bundle (.octest) name I kept having otest crash with exit code 1.
Wrong path in environment variables. Sean tutorial has lots of follow-up questions giving some insight on what other people tried. The set I have now seems to work so I suggest you start with this.
You may get some message in the console which might lead you to think something is wrong with your environment variables. You may notice a message regarding CFPreferences. This message is not preventing the tests from running properly so don't focus on it f you have problems running otest.
Last once everything is working you will be able to stop at breakpoints in your tests.
One last thing...
I've read on many blogs that the main limitation of the integrated XCode SenTestKit is that tests cannot be run while building the application. Well as it turns out this is in fact quite easy to manage. You simply need to add your Logic tests bundle as a dependency to your application project. This will make sure your logic tests bundle is built, i.e. all tests are run, before your application is built.
To do this you can drag and drop your logic test bundle onto your application target.
This post is intended as a "How-to" more than a real question. Therefore this answer is just meant to allow me to mark the "How-to" as "answered". This will probably be flagged by the community as irregular. I'm up for suggestions on where to post future "How-to" articles.
One final note though on this topic.
For those who still wonder whether writing unit tests is worth it I would definitely say Yes!
I am currently writing an application with CoreData and retrieval of data from a web service (xml parsing). The complete model can be tested and debugged without having to:
run the actual application on the simulator or device. Not having to use the device to run the tests is a huge gain of time. It's the difference between 2 minutes and 5 seconds per run.
without the need to create views or controllers when testing the model. The complete development and testing can focus on the model only in the first iteration. Once the model is cleared for integration the rest of the development can follow.
To debug the xml parsing I can simply use "hard-coded" files which I completely control.
The crux is of course to write the tests as you implement features in the code. It really is a time saver down the line in terms of debugging of the complete application.
Voilà, I'll leave it at that.
I was able to run the test case in debugger in the following simple steps:
Product > Build For > Testing
Put a break point in part of the test you want to debug
Product > Test
This is on Xcode 6.0.1 and seems much more convenient than the long procedure described above.
Very often, when I run my unit tests for my iPhone project, XCode feels like making the actual errors disappear from the errors and warnings group. These errors are often under the general sub-item of that group, and often when I need to read the text of the error in detail, all errors disappear and all I have left are the build warnings. Has anyone else seen this behavior and is there a way to fix it?
Edit: I forgot to mention; this seems to happen when i have errors that are not tied to any file (it says Line Location:0 in the second column of the error list). If there aren't any errors there (when generally the only errors are failed assertions) then it seems to work ok.
I haven't seen this behavior but what you describe sounds like a bug to me. You should submit it to apple.
It's hard to follow what you're talking about. What I can deduce is that you:
Build a Unit Test target
See the Errors and Warnings in an item in the Build Results window
Do something you don't explain to "read the text of the error in detail"
See the errors disappear (from the build results window?) but the warnings remain
It would help to see a screen shot of your project when it's doing what you want, before the errors disappear, and to learn what you are doing right before they go away.
This is probably happening because you have multiple targets with dependencies.
One target is dependent on another (usually unit tests) and the unit tests get built and their warnings/errors show up. Then, the main target gets built and its warning/errors show up. Since they are different targets, they second batch shows up over the first batch.
Assuming this is the problem, you can see the first batch by manually changing your target temporarily.