GoogleTest naming conflicts
Michael Harrington
GTest is causing a lot of problems. Both frameworks define TEST,
UnitTest, and others.
How can I resolve these conflicts?
Vlad Losev
The situation with non-macro constructs is simpler. Google Test (as well as Google Mock) defines its names in the namespace testing. Unless you use 'using namespace testing' directive, you will not have any conflicts. To use unqualified names of gMock constructs, import each one you need explicitly with the using declaration. For example:
using ::testing::InSequence;
If you are not using the 'using namespace testing' directive and still see conflicts, please let us know.
Regards,
Vlad.
Michael Harrington
I actually worked out a hacked up structure that avoids GMock having
to include gtest.h at all. It ended up being a nice fix for us because
we get the same user experience, and I think it would also be good for
GTest users because you explicitly include GTest, making it clear to
other developers which testing framework you're using. I can submit
the changes if you're interested.
By the way, I submitted a patch for MinGW support earlier today:
http://code.google.com/p/googlemock/issues/detail?id=57
>
>
>
> > I want to use UnitTest++ along with GMock, but GMock's need to include
> > GTest is causing a lot of problems. Both frameworks define TEST,
> > UnitTest, and others.
>
> > How can I resolve these conflicts?
>
> Currently, there is no way to resolve the TEST macro conflict short of
> commenting it in gtest's code. This is definitely a problem, and I have
> logged issue 162
Zhanyong Wan (λx.x x)
>
> Cool, thanks for the quick reply.
>
> I actually worked out a hacked up structure that avoids GMock having
> to include gtest.h at all. It ended up being a nice fix for us because
> we get the same user experience, and I think it would also be good for
> GTest users because you explicitly include GTest, making it clear to
> other developers which testing framework you're using. I can submit
> the changes if you're interested.
I'm interested. Could you please upload a patch? Thanks.
> By the way, I submitted a patch for MinGW support earlier today:
> http://code.google.com/p/googlemock/issues/detail?id=57
>
> On Jul 9, 4:22 pm, Vlad Losev <vl...@google.com> wrote:
>> Hi Michael,
>>
>> On Thu, Jul 9, 2009 at 11:07 AM, Michael Harrington <kibi...@gmail.com>wrote:
>>
>>
>>
>> > I want to use UnitTest++ along with GMock, but GMock's need to include
>> > GTest is causing a lot of problems. Both frameworks define TEST,
>> > UnitTest, and others.
I'm also interested in why you chose UnitTest++ over gtest. Did you
run into any problem using gtest? Is there any UnitTest++ feature you
like that gtest doesn't provide? Thanks.
>>
>> > How can I resolve these conflicts?
>>
>> Currently, there is no way to resolve the TEST macro conflict short of
>> commenting it in gtest's code. This is definitely a problem, and I have
>> logged issue 162
>> <http://code.google.com/p/googletest/issues/detail?id=162>to track
>> that. You can star the issue to get updates.
An alternative to changing gtest is to use gmock this way:
#include <gtest/gtest.h>
#include <gmock/gmock.h>
#undef TEST
#include <unittest++.h> // Whatever header UnitTest++ uses.
You might want to put the above sequence in a header (e.g. testfx.h)
for convenience.
>>
>> The situation with non-macro constructs is simpler. Google Test (as well as
>> Google Mock) defines its names in the namespace testing. Unless you use
>> 'using namespace testing' directive, you will not have any conflicts. To use
>> unqualified names of gMock constructs, import each one you need explicitly
>> with the using declaration. For example:
>>
>> using ::testing::InSequence;
>>
>> If you are not using the 'using namespace testing' directive and still see
>> conflicts, please let us know.
>>
>> Regards,
>> Vlad.
>
--
Zhanyong
Michael Harrington
> I'm also interested in why you chose UnitTest++ over gtest. Did you
> run into any problem using gtest? Is there any UnitTest++ feature you
> like that gtest doesn't provide? Thanks.
UnitTest++, and it's what we're using for the time being. GTest looks
good, even though I haven't investigated too deeply, and it may be
something we start using in the future.
> An alternative to changing gtest is to use gmock this way:
>
> #include <gtest/gtest.h>
> #include <gmock/gmock.h>
> #undef TEST
> #include <unittest++.h> // Whatever header UnitTest++ uses.
hoping for a solution that wouldn't expose GTest and potentially cause
awkward problems down the road. Plus it seemed like it was The Right
Thing to have the user explicitly state what testing framework they
want to use, even if the line is already blurred with GMock being
built on GTest.
Zhanyong Wan (λx.x x)
>
>> I'm interested. Could you please upload a patch? Thanks.
>
> Patch is uploaded to the TEST macro issue: http://code.google.com/p/googletest/issues/detail?id=162
Thanks!
Before we could accept a patch from you, we need to ask you to sign
the CLA. Please see
http://code.google.com/p/googletest/wiki/GoogleTestDevGuide#Contributing_Code
for details.
Also, could you upload the patches to the code review site such that I
can make comments? The instructions are at
http://code.google.com/p/googletest/wiki/GoogleTestDevGuide#Submitting_Patches
>> I'm also interested in why you chose UnitTest++ over gtest. Did you
>> run into any problem using gtest? Is there any UnitTest++ feature you
>> like that gtest doesn't provide? Thanks.
>
> Nothing like that. GTest just wasn't around when we decided to go with
> UnitTest++, and it's what we're using for the time being. GTest looks
> good, even though I haven't investigated too deeply, and it may be
> something we start using in the future.
>
>> An alternative to changing gtest is to use gmock this way:
>>
>> #include <gtest/gtest.h>
>> #include <gmock/gmock.h>
>> #undef TEST
>> #include <unittest++.h> // Whatever header UnitTest++ uses.
>
> Given the conflicts I already saw in my tiny test run, I was really
> hoping for a solution that wouldn't expose GTest and potentially cause
> awkward problems down the road. Plus it seemed like it was The Right
> Thing to have the user explicitly state what testing framework they
> want to use, even if the line is already blurred with GMock being
> built on GTest.
>
Thanks,
--
Zhanyong
Michael Harrington
> for details.
Done and done.
> Also, could you upload the patches to the code review site such that I
I don't see the GMock or GTest projects listed on there.
Zhanyong Wan (λx.x x)
>
>> Before we could accept a patch from you, we need to ask you to sign
>> the CLA. Please seehttp://code.google.com/p/googletest/wiki/GoogleTestDevGuide#Contribut...
>> for details.
>
> Done and done.
Thanks!
>> Also, could you upload the patches to the code review site such that I
>> can make comments? The instructions are athttp://code.google.com/p/googletest/wiki/GoogleTestDevGuide#Submittin...
>
> I don't see the GMock or GTest projects listed on there.
The code review site doesn't have the concept of individual projects,
so you won't see gtest and gmock listed there. Just follow the
instructions to upload a snapshot:
Please do submit code. Here's what you need to do:
1. Normally you should make your change against the SVN trunk
instead of a branch or a tag, as the latter two are for release
control and should be treated mostly as read-only.
2. Decide which code you want to submit. A submission should be a
set of changes that addresses one issue in the Google Mock issue
tracker. Please don't mix more than one logical change per submittal,
because it makes the history hard to follow. If you want to make a
change that doesn't have a corresponding issue in the issue tracker,
please create one.
3. Also, coordinate with team members that are listed on the issue
in question. This ensures that work isn't being duplicated and
communicating your plan early also generally leads to better patches.
4. Ensure that your code adheres to the Google Mock source code style.
5. Ensure that there are unit tests for your code.
6. Sign a Contributor License Agreement.
7. Create a patch file using svn diff.
8. We use Rietveld to do web-based code reviews. You can read about
the tool here. When you are ready, upload your patch via Rietveld and
notify googl...@googlegroups.com to review it. There are several
ways to upload the patch. We recommend using the upload_gmock.py
script, which you can find in the scripts/ folder in the SVN trunk.
Let me know if you encounter any problem. Thanks!
--
Zhanyong