Test executable failing only when run in ctest - cmake

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.

Related

How to cleanup files created by GTest tests run with CMake

I have some tests written with gtest and I run them with ctest from CMake.
As a result of the test there are files created, that should be removed before the next run.
There are two approaches I see:
Remove files as a part of test execution from the test binary (calling system() from the fixture doesn't feel really good)
Remove files in make test run (which I have no idea how to do properly)
So which approach is better and what is the best way to do it?

How can I execute my tests in a different directory on CircleCI?

I'm running my continuous integration on CircleCI, and have a hard dependency in my tests that they must be run from /vagrant.
How can I copy my files there, and execute all my tests from there?
Thanks

How to run Clojure code before each "lein test"?

How can I run some Clojure code before tests in test files are run?
I'd like to have some piece of Clojure code to be called either before running all the tests (say by doing lein test at the root of my lein project) or before running indidual tests. I don't want to duplicate that piece of code in several .clj files.
How can I do that? Is there some "special" .clj file that can be run before any test is run?
You probably want to use test fixtures. This question has a good answer on it that can get you started.

ctest tests are always enabled, I want to disable them

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.

Running GWTTestCase on Already Compiled Module

I have an automated build script which involves unit testing of some GWT Modules in production mode. It appears that when these tests are run, they recompile the GWT module.
However, earlier in the build script, I have already compiled the modules. This is an obvious waste of effort. Does anybody know of any way to test a GWTTestCase to run in production mode, on modules that were already compiled.
I don't mind losing stacktraces or any information, because the build server only informs developers of which tests fails, and expects them to debug in their own environment.
This will be helpful for you
The main class in the test infrastructure is JUnitShell. To control aspects of how your tests execute, you must pass arguments to this class. Arguments cannot be passed directly through the command-line because normal command-line arguments go directly to the JUnit runner. Instead, define the system property gwt.args to pass arguments to JUnitShell.
For example, to run tests in production mode (that is, run the tests afer they have been compiled into JavaScript), declare -Dgwt.args="-prod" as a JVM argument when invoking JUnit. To get a full list of supported options, declare -Dgwt.args="-help" (instead of running the test, help is printed to the console).
Running your test in Production Mode
When using the webAppCreator tool, you get the ability to launch your tests in either development mode or production mode. Make sure you test in both modes - although rare, there are some differences between Java and JavaScript that could cause your code to produce different results when deployed.
If you instead decide to run the JUnit TestRunner from command line, you must add some additional arguments to get your unit tests running in production mode. By default, tests run in development mode are run as normal Java bytecode in a JVM. To override this default behavior, you need to pass arguments to JUnitShell
-Dgwt.args="-prod"
Well, I found a solution, but it is not elagant. I modified JUnitShell.maybeCompileForWebMode method, you should add VM argument -Dcompile=false to prevent compilation while running unit tests . You can get modified version of JUnitShell from here .