Ось типовий код C ++:
foo.hpp
#pragma once
class Foo {
public:
void f();
void g();
...
};foo.cpp
#include "foo.hpp"
namespace {
const int kUpperX = 111;
const int kAlternativeX = 222;
bool match(int x) {
return x < kUpperX || x == kAlternativeX;
}
} // namespace
void Foo::f() {
...
if (match(x)) return;
...Це схоже на гідний ідіоматичний код C ++ - клас, хелперна функція, matchяка використовується методами Foo, деякі константи для цієї хелперної функції.
А потім я хочу написати тести.
Було б цілком логічно написати окремий тест для одиниць match, тому що це зовсім нетривіально.
Але він знаходиться в анонімному просторі імен.
Звичайно, я можу написати тест, який би зателефонував Foo::f(). Однак це не буде хорошим тестом, якщо Fooвін важкий і складний, такий тест не ізолюватиме перевіреного від інших непов'язаних факторів.
Тому я повинен перемістити matchі все інше з анонімного простору імен.
Питання: який сенс вводити функції та константи в анонімний простір імен, якщо це робить їх непридатними в тестах?
Деяка ідея у тестуванні блоку C ++ у коді без імені безіменного імені ... але «суть» у тому, що інкапсуляція хороша. Зрештою, це та сама проблема, що і у функцій приватних членів: їх не можна протестувати без нав'язкового характеру, але ви не хочете відмовлятися від інформації, прихованої для тестування одиниць (наприклад, stackoverflow.com/a/3676680/3235496 ).
—
manlio
Ваш випадок концептуально не сильно відрізняється від випадку тестування (чи не тестування) приватних методів. Тож, коли ви шукаєте "тест-одиничне тестування" тут, у програмістів, ви отримаєте безліч відповідей, які зможете застосувати безпосередньо до своєї справи.
—
Док Браун
@DocBrown Мене не запитують, як тестувати функції anon. простори імен. Я запитую "навіщо вводити код у anon. Простори імен?" (див. текст у кінці запитання). Звинувачуйте Іксрека в зміні заголовка на щось інше.
—
Абікс
@Abyx: в тих інших відповідях, про які я згадував вище, ви знайдете великий консенсус багатьох експертів тут про те, що перевірити приватні методи дійсно погано, і що зловживання
—
Doc Brown
friendключовим словом для цієї мети не рекомендується. Поєднуйте це з вашим припущенням що якщо обмеження методу призводить до ситуації, коли ви більше не можете його тестувати, це означає, що приватні методи не були б корисними.
foo.cpp, а не в заголовку! ОП, здається, добре розуміє, що не слід ставити не заголовки імен у заголовок.