On 28.01.2015 01:38, Robert Dailey wrote:
I suspect that per David's suggestion, CTest would essentially do what
you're doing but in a more thorough manner (based on the test
framework used). So essentially CTest will need:
- A new command line parameter that specifies the test framework
-
I have two more suggestions for whoever takes on this work.
One: add a new CMake command add_unit_test_container (or
add_unit_tester or a better name ... ?) which names the DLL or
executable file containing the unit tests. Give it properties to
indicate how to extract a list of tests from it
@David
I agree with your point about unit test initialization. Perhaps
instead of running a test multiple times, we can inspect the output of
a test that is run 1 time and assuming it spits out success/failure
details for individual test cases, we can simply parse that output
into appropriate
I'm sure it's possible, as long as CDash can handle the flood of test results.
CTest is responsible for taking add_test (or whatever the new CMake
command will be called) calls and transforming them into Test.xml
files for sending to CDash. As long as you can read the output of
running the unit
I suspect that per David's suggestion, CTest would essentially do what
you're doing but in a more thorough manner (based on the test
framework used). So essentially CTest will need:
- A new command line parameter that specifies the test framework
- Functionality to parse the contents of source
Hi all.
I've run into this problem as well - I think first-class support for this
in CTest would be a most useful feature.
And I would like to nominate Boost.Test into the list of frameworks
considered for support, if possible.
Petr
On Wed, Jan 28, 2015 at 1:38 AM, Robert Dailey
Hello,
This looks a little like google test. For a project I just created a CMake
macro which grepped through the test files for the test cases and adds them one
by one. Certainly features could be added to better support text fixtures.
Hope this gives you some inspiration:
It's only a chicken and egg problem if you constrain yourself artificially.
When you define a new unit test source file, there are two things you
need to do:
(1) add it to its executable
(2) write an add_test line that invokes that specific unit test
You could possibly encapsulate those actions
I wouldn't say this is an artificial problem. let me go into more detail.
A single test can define any number of test cases. These are unknown
to CMake scripts, as they are written and defined in code. The ideal
solution is to have the test program output a list of all test cases
and based on
The best thing to do would be to make CTest aware of unit test
frameworks like this, and have it be automatic.
Support for cppunit, gtest and Catch (and any other popular ones)
would all be appreciated by many, I'm sure.
Got time to dig into ctest a little bit?
D
On Tue, Jan 27, 2015 at
Can you run a command that executes one test case at a time, or do you
have to run all 50 when you execute the tests for a library?
ctest just runs whatever you give it with add_test -- if you want to
filter a collection of unit tests to run only a single unit test, then
the unit test framework
I believe so, but then you run into the chicken and egg problem:
I need to fully build all unit tests in order to know all the test
cases, but I need to define the tests at the generation phase (before
build).
I'm just not sure how to handle this. The best i can think of is to
generate 1 test
12 matches
Mail list logo
