Listing all test classes
Alan Baljeu
1) Ask for --gtest-list-tests
2) Type in a wildcard to run one or more tests.
This was fine but now we have too many tests to list them all. I want
to list all test classes instead.
To be precise, if I have TEST(Foo, Bar), I want Foo listed. For TEST_F
(A, N) I want A listed.
Then after I pick A, I can run A.* or I would like to see a list of
tests under A.
Suggestions?
Josh Kelley
Will
gtest_project --gtest_list_tests | grep -v '^ '
meet your needs?
--
Josh Kelley
Alan Baljeu
No because I'm not running from the command line but from a C++ function call.
Alan Baljeu
--
Josh Kelley
__________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
http://ca.toolbar.yahoo.com.
Josh Kelley
> No because I'm not running from the command line but from a C++ function call.
Do you have a C++ function call that's executing a Google Test project
in a subprocess, or are you calling Google Test functions directly
(such as changing flags around and calling RUN_ALL_TESTS)?
If you're executing a Google Test project in a subprocess, you can
execute grep -v '^ ', or you can have your C++ code do the equivalent
of grep -v '^ '.
If you're calling Google Test functions directly, then the event
listener interface is probably your best bet:
http://docs.google.com/Doc?id=dhspb9bn_6gqdknqhp
It should be currently available in SVN. You can use
total_test_case_count and GetTestCase to iterate over all test cases.
Or, until the event listener interface is formally released, you can
switch to running a Google Test project in a subprocess.
--
Josh Kelley
Zhanyong Wan (λx.x x)
>
> On Mon, Jul 20, 2009 at 11:39 AM, Alan Baljeu<alanb...@yahoo.com> wrote:
>> No because I'm not running from the command line but from a C++ function call.
>
> Do you have a C++ function call that's executing a Google Test project
> in a subprocess, or are you calling Google Test functions directly
> (such as changing flags around and calling RUN_ALL_TESTS)?
>
> If you're executing a Google Test project in a subprocess, you can
> execute grep -v '^ ', or you can have your C++ code do the equivalent
> of grep -v '^ '.
Agreed. It shouldn't be hard to iterate over the lines and skip the
ones starting with a space.
OTOH, it's best not to depend on the output format of
--gtest_list_tests. That format is meant for human. In theory it can
change over time, breaking your assumption. Talking to the test
reflection API (when it's ready) is a safer bet.
> If you're calling Google Test functions directly, then the event
> listener interface is probably your best bet:
Yes, when it's ready. To be precise, you probably won't need to
implement a listener using the full API. What you can do is to walk
through the test cases directly using the reflection API (part of the
listener API), as Josh described.
> http://docs.google.com/Doc?id=dhspb9bn_6gqdknqhp
> It should be currently available in SVN.
It's not quite there yet. Though we hope it won't take too long.
> You can use
> total_test_case_count and GetTestCase to iterate over all test cases.
> Or, until the event listener interface is formally released, you can
> switch to running a Google Test project in a subprocess.
>
> --
> Josh Kelley
>
--
Zhanyong
Alan Baljeu
Thanks for the advice Josh.
I am running the test in-process. No it isn't possible to run as a separate process, as I'm testing a DLL embedded in a foreign app which is VERY slow to start. The tests are therefore embedded in this DLL. The event listener interface sounds like the plan.
Alan Baljeu
----- Original Message ----
From: Josh Kelley <jos...@gmail.com>
To: Alan Baljeu <alanb...@yahoo.com>
Cc: Google C++ Testing Framework <googletes...@googlegroups.com>
--
Josh Kelley
__________________________________________________________________
The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
Vlad Losev
Agreed. It shouldn't be hard to iterate over the lines and skip the
On Mon, Jul 20, 2009 at 8:54 AM, Josh Kelley<jos...@gmail.com> wrote:
>
> On Mon, Jul 20, 2009 at 11:39 AM, Alan Baljeu<alanb...@yahoo.com> wrote:
>> No because I'm not running from the command line but from a C++ function call.
>
> Do you have a C++ function call that's executing a Google Test project
> in a subprocess, or are you calling Google Test functions directly
> (such as changing flags around and calling RUN_ALL_TESTS)?
>
> If you're executing a Google Test project in a subprocess, you can
> execute grep -v '^ ', or you can have your C++ code do the equivalent
> of grep -v '^ '.
ones starting with a space.
OTOH, it's best not to depend on the output format of
--gtest_list_tests. That format is meant for human. In theory it can
change over time, breaking your assumption. Talking to the test
reflection API (when it's ready) is a safer bet.
Yes, when it's ready. To be precise, you probably won't need to
> If you're calling Google Test functions directly, then the event
> listener interface is probably your best bet:
implement a listener using the full API. What you can do is to walk
through the test cases directly using the reflection API (part of the
listener API), as Josh described.
Actually, Alan will have to implement a listener, since the API is not guaranteed to provide the full listing of test cases until RUN_ALL_TESTS() is called. This means the earliest place one can use the API to enumerate test cases is the OnTestProgramStart() event.
It's not quite there yet. Though we hope it won't take too long.
Unfortunately, we have discovered that the current design has some undesirable interactions with the existing functionality, and we are still trying to resolve this issue. We also had to add two more events (and renamed two existing ones) for better compatibility with repeated test. Before, there was no events to correctly handle multiple iterations specified with the gtest_repeat flag. You may have noticed, the current implementation of XML output also doesn't handle them well.
I'll update the issue when the new design is finished.
--
> You can use
> total_test_case_count and GetTestCase to iterate over all test cases.
> Or, until the event listener interface is formally released, you can
> switch to running a Google Test project in a subprocess.
>
> --
> Josh Kelley
>
Zhanyong
Regards,
Vlad
Zhanyong Wan (λx.x x)
Good point.
This behavior is inconvenient and can be surprising. We should fix it
such that all tests have been registered when InitGoogleTest()
returns.
http://code.google.com/p/googletest/issues/detail?id=167
--
Zhanyong
Vlad Losev
I have also added this to the new Unresolved Issues section at the end of the document that tracks all issues together.
--
Zhanyong
Alan Baljeu
So it sounds like you are saying the reflection API is unstable and you are working on it. Any projection when it will be stable? I know I can live without this for quite some time, but once the number of tests gets up to the hundreds, a new pattern will be needed.
Alan
__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!
Vlad Losev
So it sounds like you are saying the reflection API is unstable and you are working on it. Any projection when it will be stable? I know I can live without this for quite some time, but once the number of tests gets up to the hundreds, a new pattern will be needed.
Event listener API is the top priority feature for Google Test now, so it should be done soon.