I have a core project that does not run as an application, its only "product" is to build and run a script. This project was created in Xcode 3, and was working great. Running a build would run the test script, no hassle.
Upgrading to Xcode 4, my script no longer runs. I haven't made any changes to the project, but there are obviously some differences. I checked out the build settings, and it looks like the script is piping results to /tmp/RunUnitTests.out, and the contents of this file are:
/Developer/Tools/RunUnitTests:68: note: RunUnitTests exited without running tests because TEST_AFTER_BUILD was set to NO.
Where should this TEST_AFTER_BUILD variable be set? Is there a way to do it in the UI that I can't find, or do I need to set it somewhere else?
(I'm assuming that since Xcode 4 has reached Gold Master, it's safe to discuss these things?)
If you go to the project settings (click the folder icon, then the blue project file at the top), select your test target under TARGETS, select Build Settings, turn on All settings, find Unit Testing, The change "Test After Build" under the test target to yes.
I believe you can also find that same flag(Test After Build) in the Unit Tests section of the Build Settings for each target. It defaults to 'NO' so it needs to be changed.
Found it! I edited the "Run Script" build phase for my target, and changed the command from:
"${SYSTEM_DEVELOPER_DIR}/Tools/RunUnitTests" 1> /tmp/RunUnitTests.out
to:
export TEST_AFTER_BUILD=YES
"${SYSTEM_DEVELOPER_DIR}/Tools/RunUnitTests" 1> /tmp/RunUnitTests.out
Related
I have a project that I haven't worked on in almost 2 years, and I've started trying to get it updated and working again with the latest Xcode (7.2.1).
One problem is that the Product > Test command is disabled, even though I have a unit test target and I've updated it to use XCTest.
At first none of my tests were listed in the test navigator sidebar, but after deleting my project's folder from ~/Library/Developer/Xcode/DerivedData, the tests appeared but they're grayed out. Clearing the DerivedData doesn't seem to have had any other effect.
When I open one of my test source files, the diamonds appear in the gutter next to each test method and I can run the tests by clicking on those. This happened even before clearing DerivedData.
This is with a fresh install of Xcode, on a different computer from when I previously worked on the project.
What else can I do to get Xcode to fully recognize and enable my tests?
I got the answer on the xcode-users mailing list: http://lists.apple.com/archives/xcode-users/2016/Mar/msg00029.html
The problem is that Xcode stores the test bundle setting for a target in the scheme, and since the scheme wasn't marked as shared, I hadn't added it to the git repository. Re-selecting the test target's bundle (and making the scheme shared and adding it to the repo) fixed the problem.
I've recently moved to TFS213, did an install on a new machine.
After building one of my projects the result showed an error on MsTest. It turned out that it had invalid switches (as in Error when running unit tests from MSBuild)
Invalid switch "/publish".
Invalid switch "/publishbuild".
Invalid switch "/teamproject".
Invalid switch "/platform".
Invalid switch "/flavor".
I have found various posts online about this and have done the following :
I have installed vs2013 professional on the build-machine, in various posts it's says to install ultimate but I don't have a license for ultimate.
The problem still persists, the MsTest.exe is started from the correct location (it's only installed in C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE, and the build-process does find the MsTest executable.
for now I've disabled testing in my build-definition but that's not the 'ideal' situation ;-).
Should I just remove the invalid 'switches' or is there some other solution
TIA,
Jurjen.
I had the same issue and solved it by modifying the properties of the "Run MSTest for Test Assemblies" step in the build.
Summary of fix: I changed the Flavor, Platform and Publish properties of the "Run MSTest for Test Assemblies" step to "" (empty string).
Details of fix: I did this in a custom template but I think you could also make the change in the default template.
Disabled tests (as you did) to make sure my build would work as a baseline.
Followed instructions here to create and use to a custom template:
http://msdn.microsoft.com/en-us/library/dd647551.aspx
Tested that the Custom Template worked by adding a "Write Build Message" step to the build (per advice in article above).
Searched for (drilled down) to the "Run MSTest for Test Assemblies" step in the build. This took a long time because it is deep. I am sure there is a faster way to find it but I am not sure how.
Set Flavor, Platform and Publish properties to "" (empty string). (See photo).
Committed template changes to TFS.
Re-ran the build and it worked.
When all tests pass I don't see test results on the build results screen.
When a test fails it causes the build to fail. I don't see the test failure in the build summary but it does show up when I click "View Log".
This isn't ideal, but at least I have the tests running and preventing a build from passing when a test fails.
I made changes to Intellij Community Edition (ce). I can compile and run those changes from within the IntelliJ editor. That launches a second instance of IntelliJ ce which is running from classes containing my changes. What I want to do is just run those changes without having to first load the source, compile and run from within IntelliJ.
Netbeans made this easy by just producing an executable as a result of the build. With Intellij, it's not at all clear what has to be done. I have tried the following-
using the Run configuration Intellij itself uses to run the altered classes- this includes setting the working directory , main class, vm options and classpath. Actually, this doesn't work for reasons unknown to me.
on someone's suggestion, running dist.gant in build. This blows up with very many errors which are not helpful (no class def found errors which indicate some confusion on Intellij's part on classpaths somewhere)
Running WinLauncher.exe under bin gives the error message that it can't find VM options file (although it's in bin, (and also for good measure under bin/win with the other files which are co-located with vmoptions in the intellij directory structure for Intellij proper. )
ALl this is just harder than it should be. The solution is to provide an executable as a result of the build and place it in a predictable location.
Has anyone ever actually DONE what I am trying to do- make changes to the community source then use the resultant editor not as a project you're working with in IntelliJ but as the Intellij editor you're working through?
FOLLOW UP
User60561 had the correct answer. Just to mop up the details, in artifacts, there is a compressed file (win.zip for Windows, mac.zip for Mac etc.). In order to run your snapshot, you have to unzip this archive (after which it will have the same name, minus the zip extension) then go into folder "bin". There you'll see two executables: idea.exe and idea64.exe, for 32 and 64 bit versions, respectively. Clicking on these runs your snapshot.
Adjusting contents of the files idea.exe.vmoptions and idea64.exe.vmoptions lets you set the VM parameters to suit yourself, typically people might want to give the VM more memory through the -Xmx value.
It seems straightforward:
To build the distribution archive of IntelliJ IDEA Community Edition, execute build.xml Ant build script in the root directory of the source code. The results of the build execution can be found at out/artifacts.
https://github.com/JetBrains/intellij-community#building
So download ant, and run ant in the directory that you have it stored in. Make sure to use the commandline to launch ant in order to make sure everything is working correctly.
Initially execute getPlugins.bat/sh, then:
Use update.bat/sh according to it's instructions
Or
Click on: Main Menu | Build | IntelliJ IDEA CE build
Copy content of intellij-community\out\deploy (lib, plugins folder) into existing IJ installation (sometimes it is better to delete existing folders if they contain older dependencies or when the installation was of Ultimate version)
So, I am having a bear of a time figuring this one out. I have looked around, and cannot seem to find any information on this.
What I want to do is have my unit tests ALWAYS run EVERY time I build my code in XCode. I have read a number of posts, including this question here. I have followed the instructions to the letter, and the build will not run the tests.
What I have done:
My Test suite is a target dependency of my main build
My main build has "Test After Build" set to Yes
All of the tests under the "test" phase in the Scheme are there, and checked
If I run the tests manually - through cmd+U or the menu - the tests run. I have added a failing test to try and force the build to fail - so I can be sure they are running. The build continues to pass fine, and the tests are never run.
I am positive I have missed a step in here, but for the life of me I cannot find any documentation related to it. Anyone have any other advice or steps I should be doing?
It doesn't matter whether or not "Test After Build" is set to yes or no in your Something.app target. It is only necessary to set "Test After Build" to YES in the unit test target. Also make sure that both "Test" and "Run" are selected for your unit test target in the scheme editor under the "Build" tab options. To see the results click on the Log Navigator View > Navigators > Show Log Navigator (command 7).
In your main target's Build Phases, add a new Run Script build phase. The content of the script should be:
"${SYSTEM_DEVELOPER_DIR}/Tools/RunUnitTests"
That will run the tests - but only if it can find the .octest files generated by your project. RunUnitTests wants PRODUCT_NAME to be the name of your unit test, and WRAPPER_EXTENSION to be .octest (these are Xcode variables). If your main target is an aggregate target that has your tests AND your app as dependancies, you can probably make it work with that in mind.
I followed Apple's instructions to set up Unit Testing in my project. I followed the directions for making them dependent, so the tests run with every build of my main project. This works, and when my tests pass, the application runs; when they don't, I get build errors on the lines of the unit tests that failed.
I would like, however, to be able to step through my application code when the tests are failing, but can't get Xcode (3.2.5) configured properly. The project is a Mac project, not iOS.
I tried the instructions here and here, but execution never stopped at the breakpoints I set, neither in the the unit test code or in my application code. After following the first set of instructions, the breakpoints I set turned yellow with blue outlines, and I don't know what that meant, either. What do I need to do to step through my tests?
Update
I found another page attempting to solve this problem (here) by adding arguments and environment variables to my main executable, but again, those didn't cause execution to stop at my breakpoints. I also noticed that my test's (copious) log statements aren't showing up in my Debugger Console, either.
I also found out that the yellow breakpoints mean the code there can't be found at runtime. These are in my test case class, so that definitely seems to explain why those aren't firing.
I usually have no problem debugging my OCTest tests with Xcode 3.2, including halting at breakpoints.
The basic idea is to tell gdb to launch otest with your bundle as argument. You will do that by adding /Developer/Tools/otest as a custom executable to your Xcode project, then your OCTest bundle name as the sole argument (choose "Edit Active Executable otest" in the Project menu, and in the second tab add a line with Foo.octest in the top box to debug the Foo test).
Now if you hit the debug button it will start debugging your test bundle right now, and will stop at the declared breakpoints (if you hit build and debug it might not start if the test does not pass). Also note that you will maybe have to set an environment variable to YES to disable garbage collection (in the bottom box of the same "Arguments" tab), otest will tell you exactly which if you need.
If you did everything above and are still unable do step into your test code, this might either be because it is compiled with debug symbol generation turned off - check your debug build settings, but most likely because the test code is not recompiled at all. I say most likely, since your logs are not showing in the console, NSLog should write in the Xcode console. Clean your build and bin folders manually, sometimes when you change a path or a name you end up loading obsolete code. You might also want to check that the file has not jumped out of the test target (is the failing test in the same not-logging file ?).
I have a variant of what Hiedi Utley posted at http://hiediutley.wordpress.com/2011/03/08/xcode3-debugging-ios-unit-tests/. What I did not like about it is the duplication of unit test bundle targets, one that contained a Run Script phase to execute the unit tests after building, and another that did not run the unit tests. I had noticed in the Get Info pane for the Run Script phase the toggle "Run script only when installing" and thought that that would be a way to toggle between running the unit tests in normal mode and running them in the debugger.
As per Hiedi's instructions, create a new Executable item, say LogicTestsGDB. Configure it like so:
General Tab:
Path: Developer/usr/bin/otest (No leading /)
Path Type: Relative to Current SDK
Set the working directory to: Build Products directory
Arguments Tab:
Arguments: Your UnitTest Bundle (eg. LogicTests.octest)
Variables to be set in the environment
DYLD_LIBRARY_PATH ... : ${BUILD_PRODUCTS_DIR}:${DYLD_LIBRARY_PATH}
DYLD_FRAMEWORK_PATH . : ${SDKROOT}/Developer/Library/Frameworks
DYLD_ROOT_PATH ...... : ${SDKROOT}
IPHONE_SIMULATOR_ROOT : ${SDKROOT}
OBJC_DISABLE_GC : YES
DYLD_NEW_LOCAL_SHARED_REGIONS : YES
DYLD_NO_FIX_PREBINDING : YES
CFFIXED_USER_HOME : ${HOME}/Library/Application Support/iPhone Simulator/
Done. Now to debug your unit tests,
Expose the bundle's build phases and double-click on the Run Script phase.
Check the Run script only when installing option
Set the Active Target to be the unit test bundle (eg. LogicTests.octest).
Set the Active Executable to be the new executable created (eg. LogicTestsGDB)
Click Build and Debug
To run normally, executing unit tests as part of the build phase of the application:
Expose the bundle's build phases and double-click on the Run Script phase.
Uncheck the Run script only when installing option
Set the Active Target to be the application being built
Set the Active Executable to be the application being built
To automate the steps above, I created a simple AppleScript script that toggles between the two states:
property kApplicationName : "MyApp" -- name of the normal application to build
property kUnitTestName : "LogicTests" -- name of the bundle target to debug
property kUnitTestRunner : "LogicTestGDB" -- name of the executable to use when debugging the unit test bundle
tell application "Xcode"
tell the active project document
set theTarget to first target whose name is kUnitTestName
set thePhase to first run script phase of theTarget
if name of active target is kApplicationName then
set active target to theTarget
set theExecutable to first executable whose name is kUnitTestRunner
set active executable to theExecutable
set run only when installing of thePhase to true
else
set theTarget to first target whose name is kApplicationName
set active target to theTarget
set theExecutable to first executable whose name is kApplicationName
set active executable to theExecutable
set run only when installing of thePhase to false
end if
return "Targeting " & (name of active executable)
end tell
end tell
I also tried the solutions in the links you provided with, but none worked for me, too. But then I found this one: http://hiediutley.wordpress.com/2011/03/08/xcode3-debugging-ios-unit-tests/ -- it works like a charm :) Fresh stuff, too.
develop your unit tests so they wrap a program which resides in a project which has a target, then just open the dependent project and work in it. this would likely be a project with a library and an executable which calls through the library (2 targets). then you can just open the project and debug, while your unit tests in the dependency would then call through this library. this is a more modular approach.
good luck
The only thing that ended up working for me was upgrading to Xcode 4. It integrates beautifully. There was a little bit of pain in moving over to it, but now that it's over with, the integration is great. I'm fully able to step through my tests and application code.