When trying to build the unit tests created using the default XCode Unit Test bundle target, it looks like it's stuck on the "Run custom shell script 'Run Script'" phase.
I also notice a high cpu usage on process "otest" to the point where the fans kick in within seconds.
The only useful message I see when expanding the line is
/Developer/Tools/RunPlatformUnitTests.include:419: note: Running tests for architecture 'i386' (GC OFF)
Couldn't open shared capabilities memory GSCapabilities (No such file or directory)
The only option I have at that time is to stop the build.
Have to say I was running unit tests perfectly fine up to this moment but can't say for sure what I did to cause that.
That's on XCode 3.2.4
After updating to 3.2.5 now the run script does fail with an error
Test rig '/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator4.2.sdk/Developer/usr/bin/otest' exited abnormally with code 138 (it may have crashed).
Guess they problem is related?
Did find some answers on SO about how exception handling now works differently when using NSInvocation (which otest seems to use) but not really a solution to this.
I had this happen to me. I made it go away by scrapping my old testing target profile, creating a new one, and pointing all my tests to it. I was too frustrated to compare the profiles line by line to figure out what had changed.
This looks like an infinite loop to me. Try adding some NSLog statements and/or debugging your tests with gdb (by adding otest as a custom executable).
This happened to me after updating to Xcode 9 and using script for updating localizable strings file, a minor bug caused the script to never finish. After updating BartyCrouch, everything worked normally.
https://github.com/Flinesoft/BartyCrouch/issues/66
Related
Recently, I ran into an issue at work. To summarize it, I am currently working on writing test cases for an internal Flutter project. This had been working fine for a while, but after my summer vacation, it started breaking. It took me a while to figure out what roughly was going on, but I hen discovered that running integration tests generated a file named generated_main.dart under .dart_tool/flutter_build/. This was working just fine when using integration tests, however, it caused unit tests to fail due to not even loading.
I managed to identify the relevant line of code in the generated file as line eight: import 'file:///tmp/flutter_tools.WJSDQT/flutter_test_listener.YHXZLS/listener.dart' as entrypoint;. The capitalized strings of random characters are indeed random, apparently referring to a temporary path that only exists for the unit test's duration. Unit tests throw (even though not always reliably): .dart_tool/flutter_build/generated_main.dart:8:8: Error: Error when reading '/tmp/flutter_tools.WJSDQT/flutter_test_listener.YHXZLS/listener.dart': No such file or directory.
Surprisingly, there seem to be no issues when deleting the generated file. I have now added a print statement to the integration tests that tells whoever ran them that they need to delete the generated file. But this is obviously not a good solution long-term. Is there a way to disable this behavior so that testing does not become unnecessarily more complicated?
My environment is Ubuntu 20.04 LTS with Flutter 2.5.0-5.1.pre on channel beta, using Android Studio 2020.3.1. I am not currently able to test for this behavior on other platforms. The program needs to run on Linux. The test package version is 1.17.10, the newest one compatible with other dependencies.
Thank you in advance for your time.
I am using a powershell script that internally calls msbuild to build my solutions. This works in principle, so the solution files are ok.
I can repeat the build, it works flawlessly.
But the build hangs
the first time I start the script (after reboot)
after some time / actions during the work day, no idea what changes
So my suspicion is, that msbuild is using some component that is not loaded when I reboot / that is unloaded during the work.
But I have no clue how to find the problem...
I am using this exe:
C:\Program Files (x86)\MSBuild\14.0\bin\MsBuild.exe
Any ideas?
For anybody running into this issue: Roslyn does a "shared compilation" by default, which means that results of compiles are used for further compilations to gain speed. You can switch this of by providing "False" for UseSharedCompilation in VBPROJ files or using a similar switch for MsBuild. Switching this off will do slower compiles but the run does not hang.
To do this in-editor you open the automation tab, connect to the session and choose which tests to run.
How do you do it from the command line?
(NB. not compiling UnrealEngine/Engine/Build/BatchFiles/* comprehensively covers both building the application and compiling it. Specifically, given that you have code that is 100% happy to compile, how do you kick the test suite off)
--
Here's some more info, from recent testing on 4.10:
Running tests from the editor:
UE4Editor Project.uproject -ExecCmds="Automation RunTests MyTest"
Notice the absence of the -Game flag; this launches the Editor and runs the tests successfully in the editor console.
Running the game engine and using the 'popup log window':
UE4Editor Project.uproject -Game -ExecCmds="Automation RunTests MyTest" -log
This runs the game in 'play' mode, pops up an editor window; however, the logs stop at:
LogAssetRegistry: FAssetRegistry took 0.0004 seconds to start up
...and the game never closes or executes the tests.
Running the game engine and logging to a file:
UE4Editor Project.uproject -Game -ExecCmds="Automation RunTests MyTest" -log=Log.txt
This runs the game in 'play' mode, and then stops and never exists.
It does not appear to run any tests or log to any files.
The folder Saved/Logs does not exist after quitting the running game.
Running in the editor, test types, etc...
see: https://answers.unrealengine.com/questions/358821/hot-reload-does-not-re-compile-automation-tests.html,
Hot reload is not supported for tests; so this isn't an option.
There's also been some suggestion in various places that the test type (eg. ATF_Game, ATF_Editor) has some affect on if runs are or can be run; perhaps this is an issue to, but I've tried all kind of combinations with no success.
--
I've tried all kinds of combinations of things trying to get this working, with no success so it's time for a bounty.
I'll accept an answer which reliably:
Executes a specific test from the command line
Logs the output from that test to a file
Right, no one has any idea here or on the issue tracker.
After some serious digging through the UE4 source code, here's the actual deal, which I leave here for the next suffering soul who can't figure this out:
To run tests from the command line, and log the output and exit after the test run use:
UE4Editor.exe path/to/project/TestProject.uproject
-ExecCmds="Automation RunTests SourceTests"
-unattended
-nopause
-testexit="Automation Test Queue Empty"
-log=output.txt
-game
On OSX use UE4Editor.app/Contents/MacOS/UE4Editor.
Notice that the logs will, regardless of what you supply, ultimately be placed in:
WindowsNoEditor/TestProject/Saved/Logs/output.txt
or
~/Library/Logs/TestProject/output.txt
Notice that for mac this is outside of your project directory, in, for example, /Users/doug/Library/Logs/TestProject. (Who thought that was a good idea?)
(see https://wiki.unrealengine.com/Locating_Project_Logs#Game_Logs)
You can list automation tests using:
-ExecCmds="Automation List"
...and then parse the response to find tests to run; automation commands may be chained, for example:
-ExecCmds="Automation List, Automation RunAll"
Do you mean the in-editor command line or the Windows command line?
In the editor you can use the Automation command with parameters, e.g. Automation RunAll
In the Windows command line you can specify unreal command parameters with -ExecCmds. To run all tests in your project: UE4Editor.exe YOURPROJECT -Game -ExecCmds="Automation RunAll"
For anyone still wondering, there is a bug in the editor that make it so the test list is flushed before they are run when they are started from the command-line (be it at startup or after).
This means that the editor actually compiles a list of tests to run, which is then flushed by another part of the program. The editor then thinks that it has finished running all the test and, since there is no errors, shows that they all succeeded.
I can post how to do a fix to this if anyone is interested, but it introduce another minor bug.
i got a little application which is working very well with my "debug" configuration on my phone and in simulator.
i created a adhoc provisioning profile, and added a "beta" configuration to it.
trying to launch the application with the ad-hoc configuration crashes my application immediatelly.
the console output is:
Running…
Error launching remote program: failed to get the task for process 2434.
Error launching remote program: failed to get the task for process 2434.
The program being debugged is not being run.
The program being debugged is not being run.
i also created a dist.plsit, unchecked the get-tast-allow and setted this file in my built settings under code signing.
does anyone have an idea?
thanks!
Sometimes when you change lots of things, especially build configs, xcodebuild doesn't seem to figure out which files are stale and links in old stuff that needs to be rebuilt. Try doing a Clean All or just delete your build directory from the project dir. That seems to solve most of these bizarre-ass unexplainable problems for me.
simple thing. i clicked "built and run" instead of "built".
an ad-hoc version cannot be debugged :D
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.