I just wanted to make sure I understood your proposal.
Right now, test classes want to be in the anonymous namespace so that
unit test files do not have to coordinate with each other in the
naming of test classes. With your proposal, the thing which is
exposed outside of the anonymous namespace (MyClassPeer) is based on a
thing already known to be unique (MyClass), so coordinate is not an
issue unless you have multiple unit test files testing the same class.
There are still just as many items exposed outside of the anonymous
namespace, but they are named in a way which prevents collisions.
Is that about right?
Thanks,
scott
On Tue, Mar 3, 2009 at 4:49 PM, William Chan (陈智昌)
<willc...@chromium.org> wrote:
> My old team never really used FRIEND_TEST. We found it ugly that our
> production code depended on test code. We typically used friended
> "Peer" classes defined in the unittest file, but not in the anonymous
> namespace. These are simple shims that provide access to the private
> section. It also saves on having to FRIEND_TEST each individual test
> as you add them. It looks like almost every time FRIEND_TEST is used,
> it's used for multiple tests, not just a single one. I'm not sure how
> much of a problem chrome has with build dependencies leading to
> rebuilds, but it was very annoying in google projects to add a
> FRIEND_TEST to a widely used .h file, thus forcing everyone to
> rebuild, even though you're only adding a new test.
>
> On Tue, Mar 3, 2009 at 4:30 PM, Darin Fisher <da...@chromium.org> wrote:
>> On Tue, Mar 3, 2009 at 3:55 PM, Scott Hess <sh...@chromium.org> wrote:
>>>
>>> On the Mac, code like this:
>>>
>>> namespace {
>>> class MyTest : public testing::Test {
>>> };
>>> } // namespace
>>>
>>> TEST_F(MyTest, ATest) {
>>> }
>>>
>>> generates errors like this:
>>> warning: 'MyTest_ATest_Test' has a field
>>> 'MyTest_ATest_Test::<anonymous>' whose type uses the anonymous
>>> namespace
>>> warning: 'MyTest_ATest_Test' has a base '<unnamed>::MyTest' whose type
>>> uses the anonymous namespace
>>>
>>> Removing the namespace fixes it, which is poor because we seem to want
>>> to move towards more anonymous namespace use. Putting the test case
>>> inside the namespace also fixes it, but is incompatible with
>>> FRIEND_TEST(). This seems to be a gcc 4.2 addition, per:
>>> http://gcc.gnu.org/gcc-4.2/changes.html
>>>
>>> "Members of the anonymous namespace are now local to a particular
>>> translation unit, along with any other declarations which use them,
>>> though they are still treated as having external linkage for language
>>> semantics."
>>>
>>> At this point, I'm sort of at the bleeding edge of my knowledge. For
>>> FRIEND_TEST() cases, it seems like the anonymous namespace needs to
>>> go, but elsewhere it can be changed to enclose the entire file. Does
>>> that seem reasonable for now?
>>>
>>> -scott
>>
>>
>> Assuming that you really need to use TEST_F, then it would be unfortunate to
>> lose the anonymous namespace. The anonymous namespace has allowed us to
>> have short names for helper classes used by tests without fear of colliding
>> with other short names used by other tests. (We have had those kinds of
>> conflicts in the past.)
>> We don't use FRIEND_TEST that much. Maybe we can just use #ifdef UNIT_TEST
>> to expose class APIs to unit tests?
>> -Darin
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
