[feature] specify tests to run before others

1 view
Skip to first unread message

SimoneB

unread,
Jun 26, 2010, 6:44:34 AM6/26/10
to Google C++ Testing Framework
Hi, it would be useful to have an option to run some tests before the
others. Our build environment is capable of providing names of tests
and names of files containing tests more risky, that you might want to
run before the rest to receive immediate feedback.

Zhanyong Wan (λx.x x)

unread,
Jun 28, 2010, 12:42:49 AM6/28/10
to SimoneB, Google C++ Testing Framework
Hi,

You can try the --gtest_filter flag. Suppose test A.B and C.D are
more likely to fail. You can run your test program (say, foo_test)
like this:

foo_test --gtest_filter=A.B:C.D
foo_test --gtest_filter=-A.B:C.D

The first time A.B and C.D will run. The second time everything else will run.

--
Zhanyong

Zhanyong Wan (λx.x x)

unread,
Jun 28, 2010, 2:13:58 AM6/28/10
to Simone Busoli, Google C++ Testing Framework
(adding back the list)

On Sun, Jun 27, 2010 at 11:03 PM, Simone Busoli <simone...@gmail.com> wrote:
> I am aware of the --gtest_filter switch, the feature I'm looking for is
> running A.B and C.D before all the other tests in one single run.

Thanks for clarifying. This feature is not trivial to implement.
Could you explain why it's important that you must do it in a single
run?

> 2010/6/28 Zhanyong Wan (λx.x x) <w...@google.com>

--
Zhanyong

Zhanyong Wan (λx.x x)

unread,
Jun 28, 2010, 1:50:25 PM6/28/10
to Simone Busoli, Google C++ Testing Framework
(adding back the list)

On Mon, Jun 28, 2010 at 10:46 AM, Simone Busoli <simone...@gmail.com> wrote:
> Sure. The reason is that the build server I'm using is capable of providing
> the names of the files/tests which are more likely to fail (according to
> certain rules) as environment variables, and it would be easier to provide
> them directly as command line switches to gtest instead of having gtest
> running twice by supplying it a filter and then its inverse.
> I thought that would be an interesting feature, but if you say it's not
> trivial to implement then the double run is probably the way to go.

Thanks for clarifying, Simone.

>
> 2010/6/28 Zhanyong Wan (λx.x x) <w...@google.com>
>>
>> Thanks for clarifying.  This feature is not trivial to implement.
>> Could you explain why it's important that you must do it in a single
>> run?
>

--
Zhanyong

Reply all
Reply to author
Forward
0 new messages