[Nfd-dev] UnitTesting naming convention: test suite name conflicts with class name

Junxiao Shi shijunxiao at email.arizona.edu
Wed Sep 16 07:01:57 PDT 2015


Dear folks

Since 20150901 we have adopted a new naming conventions for unit test suites: http://redmine.named-data.net/projects/nfd/wiki/UnitTesting/6 
For example, a test suite for ndn::util::Signal should be named: Util/TestSignal.

Under this rule, a test suite for ndn::security::pib::Pib should be named: Security/Pib/TestPib.
In Boost.Test, this is written as:
BOOST_AUTO_TEST_SUITE(Security)
BOOST_AUTO_TEST_SUITE(Pib)
BOOST_AUTO_TEST_SUITE(TestPib)

Each of these BOOST_AUTO_TEST_SUITE macros would declare a class named after the test suite name.
This causes the identifier “Pib” ambiguous: it refers to not only the class under test (ndn::security::pib::Pib), but also the second level test suite.

Yingdi gave two proposals:
1. name the test suite as Security/PibDir/TestPib
2. name the test suite as security/pib/TestPib

My proposal is:
• name the test suite as Security/TestPib/TestPib
• due to the existence of Pib class, all test suites for ndn::security::pib::* should have its second level named “TestPib” rather than “Pib”

My reason is:
• Yingdi’s second proposal resolves the name conflict between test suite name and class name, but it creates another conflict: “pib” refers to both the test suite and the namespace ndn::security::pib.
• Although Yingdi’s first proposal prevents the name conflict, it’s using two different rules to resolve the conflict: (a) append “Dir” (b) prepend “Test”. The purpose for prepending “Test” to the lowest-level test suite name is to resolve the name conflict, so we should reuse the same rule for resolving all conflicts.
• Having “TestPib” on two levels should be fine, because this class name is never referred to in the testing code.


Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150916/1ecfee42/attachment.html>


More information about the Nfd-dev mailing list