In ctest documentation, I see the following statement:
enable_testing: Enable testing for current directory and below.
If the ENABLE_TESTING command has been run, this command adds a test target to the current directory. If ENABLE_TESTING has not been run, this command does nothing. The tests are run by the testing subsystem by executing Exename with the specified arguments. Exename can be either an executable built by this project or an arbitrary executable on the system (like tclsh). The test will be run with the current working directory set to the CMakeList.txt files corresponding directory in the binary tree.
So, I removed ENABLE_TESTING from the current directory and above, however the tests are still working. Is it by default enabled? how can I disable the tests?
I want to disable the testing so that I can run ctest without starting all the tests. I want to add them one by one. the problem is that tests seems to be always enabled.
Related
When I create a new Mocha test file I am presented with the expected green gutter icons (▶ and ▶▶) to run each test or the suite. When I select "Run [test name]" I expect it to create a Mocha debug configuration and run it. Instead, IntelliJ creates a NodeJS run configuration, which understandably explodes in a shower of bit-flavored WTF.
If I manually create a configuration for the whole file, everything works as expected, including individual tests afterward. I am hoping that there is a setting somewhere that I have overlooked, something like "Settings -> ... -> Default Debug Configuration".
Does anyone know how I can make IntelliJ default to Mocha when a unit test is executed?
The logic used for determining what test runner is available for a given test file is based on dependencies declarations in package.json nearest to current file. Do you have 'mocha' listed as a dependency/dev dependency in your package.json? How many package.json files do you have in your project?
Note that, if Mocha is not installed locally/included in package.json, you can create a Mocha run configuration with "All in directory" selected and specify a directory where your spec files are located. In this case, clicking the gutter button in a test file inside this directory will suggest to run test with Mocha.
Note also that if you have created Node.js Run configuration with "JavaScript file" set to your mocha test file, IDEA will suggest using this configuration instead of Mocha when clicking on your tests, because explicitly created run configurations associated with current file have priority over the ones auto-generated from context. Deleting the configuration should solve the issue.
I currently have a rather large codebase that builds a number of applications each as their own seperate projects underneath one global project.
I want to be able to run CTest on this global project as part of the regular build, so if a user tries to build the codebase ("make", "make -j4", "make -C gui") that the CTest framework will always run at the very end of the project, once every target under the main project has been completed.
Is it possible to do this? I considered whether it would be possible to add another project and use add_custom_command and make it depend on the global project so that it would only run after that had completed. However, I don't think this is possible?
Are there any suggestions on a better way to achieve this? My main goal is that once a user runs "make", the very last step must be to run CTest, regardless of if you build an individual directory, target or using multiple jobs.
When I use the ctest interface to cmake (add_test(...)), and run the make target make test, several of my tests fail. When I run each test directly at the command line from the binary build folder, they all work.
What can I use to debug this?
To debug, you can first run ctest directly instead of make test.
Then you can add the -V option to ctest to get verbose output.
A third neat trick from a cmake developer is to have ctest launch an xterm shell. So add
add_test(run_xterm xterm)
in your CMakeLists.txt file at the end. Then run make test and it will open up a xterm. Then see if you can replicate the test failing by running it from the xterm. If it does fail, then check your environment (i.e. run env > xterm.env from the xterm, then run it again env > regular.env from your normal session and diff the outputs).
I discovered that my tests were wired to look for external files passed on a relative path to the top of the binary cmake output folder (i.e. the one where you type make test). However, when you run the test through ctest, the current working directory is the binary folder for that particular subdirectory, and the test failed.
In other words:
This worked
test/mytest
but this didn't work
cd test; ./mytest
I had to fixed the unit tests to use an absolute path to the configuration files it needed, instead of a path like ../../../testvector/foo.txt.
The problem with ctest and googletest is that it assumes to run one command for each test case, whilst you will have potentially a lot of different test cases running in a single test executable. So when you use add_test with a Google Test executable, CTest reports one single failure whether actual number of failed test cases is 1 or 1000.
Since you say that running your test cases isolated makes them pass, my first suspicion is that your tests are somehow coupled. You can quickly check this by randomizing the test execution order using --gtest_shuffle, and see if you get the same failures.
I think the best approach to debug your failing test cases is not to use CTest, but just run the test executable using the command line options to filter the actual test cases getting run. I would start by running only the first test that fails together with the test run immediately before when the whole test suite is run.
Other useful tools to debug your test cases can be SCOPED_TRACE and extending your assertion messages with additional information.
I have a solution with a number of nUnit tests that do not appear to run on Visual Studio Online servers. Here's what I've done so far:
Created a separate folder (outside of my branch structure) that has nUnit test adapter DLLs
Build controller is configured with a path to custom assemblies to point to nUnit folder that has adapter DLLs
Build's test Source is configured as:
" - Run tests in test sources matching *test*.dll;*test*.appx,Target platform: 'X64'"
Build controller reports during the build
Run optional script after MSBuild
Run optional script before Test
Runner Run VS Test Runner
Run Continuous Deployment
No test results afterwards.
No test results
No code coverage results
What am I doing wrong? Do nUnit tests require special attributes to run properly on VSO? Am I missing any other configuration settings?
I've followed this link when configuring: http://www.visualstudio.com/get-started/hosted-build-controller-vs#supplemental_binaries
Edit:
Test settings expanded as requested
Appreciate any help!
Well, I never setup a TFS build before, let alone an online one, until now (TeamCity fan), so I copied every single property from the screenshots and the only way I could get it to pseudo-"pass" (fully green, with no No test found. Make sure that installed test discoverers & executors warnings under Other Errors and Warnings) is when it didn't find any *test*.dll assemblies to load to begin with, rather than no [Test] methods to execute. Did you check your MSBuild log to make sure your test project assemblies are copied and match the pattern?
_CopyFilesMarkedCopyLocal:
Copying file from "C:\a\src\Alertera-Scheduler\packages\NUnit.2.6.3\lib\nunit.framework.dll" to "C:\a\bin\nunit.framework.dll".
Copying file from "C:\a\src\Alertera-Scheduler\packages\NUnit.2.6.3\lib\nunit.framework.xml" to "C:\a\bin\nunit.framework.xml".
CopyFilesToOutputDirectory:
Copying file from "obj\Debug\Alertera-Scheduler.Tests.dll" to "C:\a\bin\Alertera-Scheduler.Tests.dll".
Alertera-Scheduler.Tests -> C:\a\bin\Alertera-Scheduler.Tests.dll
Copying file from "obj\Debug\Alertera-Scheduler.Tests.pdb" to "C:\a\bin\Alertera-Scheduler.Tests.pdb".
Done Building Project "C:\a\src\Alertera-Scheduler\Alertera-Scheduler.Tests\Alertera-Scheduler.Tests.csproj" (default targets).
Done Building Project "C:\a\src\Alertera-Scheduler\Alertera-Scheduler.sln" (default targets).
Could you expand your Test source settings as well?
If you click Open Drop Folder (Build details in VS) > Diagnostics (tab in VSO) what does it say under Run VS Test Runner?
Run VS Test Runner 00:00:00
There were no matches for the search pattern C:\a\bin\*test2*.dll
There were no matches for the search pattern C:\a\bin\*test*.appx
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.