Здравствуйте, antropolog, Вы писали:

A>1) сделать функцию свободной, а не членом класса. В классе ей не место.
+1
A>2) в тестах тестировать функцию, подключая её просто через extern my_func
я бы положил ее в инклуд
A>3) ЗАКОН: никогда не дизайнить код в угоду тестам, писать всегда код так как будто тестов нет, не было и не будет.
-100

Здравствуйте, Loooser, Вы писали:

L> Простите, но вы пишите неправду.
я всегда пишу правду, могу искренне заблуждаться, но здесь явно не этот случай

L> 4) Ваш вариант...
тестировать только публичный контракт. Почему у вас возникает вообще идея тестировать имплементацию? У вас нет нужды тестировать правильность имплементации. Допишите публичный контракт и тестируйте его. Этот тест автоматом протестирует имплементацию.

L> Надеюсь я понятно объяснил в чем смысл тестирования имплементации?
да, понятно, смысла нет.

Здравствуйте, dimgel, Вы писали:

A>>black box и white box это техники тестирования софта вообще, а не кода. Тестирование кода ( юнит-тесты, например ) это и есть white box.

D>Именно.
Что именно? Ещё раз, тестирование публичных контрактов кода это и есть white box testing.

Здравствуйте, tdiff, Вы писали:

T>Тут я не знаю даже, эта позиция мне импонирует, но сомнение какое-то остаётся. Есть же правило типа "хороший код — тестируемый код".
я не вижу противоречия в "хороший код — тестируемый код" и в законе "никогда не дизайнить код в угоду тестам".

Здравствуйте, Abyx, Вы писали:

A>>2) в тестах тестировать функцию, подключая её просто через extern my_func
A>я бы положил ее в инклуд

в смысле?

Здравствуйте, tdiff, Вы писали:

T>в смысле?

Abyx советует вынести прототип в хедер и подключать его в тестах

Здравствуйте, tdiff, Вы писали:
T>2. Вытащить функцию f() в отдельный файл. Но тогда получается, что мы теряем контроль компилятора за областью видимости этой функции.
горе-то какое

отнесите ф-ию к какому-нить классу

Здравствуйте, __kot2, Вы писали:

__>отнесите ф-ию к какому-нить классу

зачем?

Здравствуйте, dimgel, Вы писали:
D>Вот ТС и дизайнил таким образом. И выяснилось, что его код невозможно протестировать. Хреновый закон, короче. Но и рассматривать тесты как что-то особенное-исключительное тоже не нужно. В случае ТС мы имеем дело с обыкновенным рефакторингом, преследующим обыкновенную для рефакторинга цель: сделать кусок логики повторно используемым, т.е. доступным кому-то ещё, в данном случае — тестам, но это непринципиально.
согласен. на самом деле основная причина, по которой людей заставляют писать тесты для своего кода это то, что дерьмовый код очень сложно тестировать, поэтому они хотят-не хотят, а начинаяют разлеплять комок костылей

Здравствуйте, tdiff, Вы писали:
T>Ну это мы переключаемся на тему необходимости тестирования приватных членов. Тут я не соглашусь, что их тестировать не надо. Через публичный интерфейс функцию толком не оттестируешь, хотя бы потому, что вызывается она не напрямую, а из какого-то другого кода, меняющего её окружение (например, как-то редактирующего входные данные или добавляющего какие-то проверки).
обычно если есть макаронистая приватная функция, реализующая достаточно сложный функционал внутри класса, то по уму ее стоит выделить в отдельный класс. таким образом и закрывается вопрос о тестировании приватных методов.

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, tdiff, Вы писали:
T>>Ну это мы переключаемся на тему необходимости тестирования приватных членов. Тут я не соглашусь, что их тестировать не надо. Через публичный интерфейс функцию толком не оттестируешь, хотя бы потому, что вызывается она не напрямую, а из какого-то другого кода, меняющего её окружение (например, как-то редактирующего входные данные или добавляющего какие-то проверки).
__>обычно если есть макаронистая приватная функция, реализующая достаточно сложный функционал внутри класса, то по уму ее стоит выделить в отдельный класс. таким образом и закрывается вопрос о тестировании приватных методов.

решается одна проблема, но появляется другая: теперь этот новый класс могут использовать все кому не лень, а задумывался он как приватный для конкретной задачи.

Здравствуйте, tdiff, Вы писали:
T>Здравствуйте, __kot2, Вы писали:
__>>отнесите ф-ию к какому-нить классу
T>зачем?
я себе вообще не могу представить, чтобы я сидел такой за компом и думал "таак, мне нужен контроль компилятора за областью видимости этой функции, чтоб ее никто случайно не вызвал". что за бред вообще? голые функции остались для совместимости с Си, в современном С++ вообще об этом не надо мозг греть — все в классах должно быть по уму

Здравствуйте, __kot2, Вы писали:

__>на самом деле основная причина, по которой людей заставляют писать тесты для своего кода это то, что дерьмовый код очень сложно тестировать, поэтому они хотят-не хотят, а начинаяют разлеплять комок костылей

+100500. Всё порывался написать нечто похожее, но ломало погружаться в спор ещё глубже. И кстати, эта фигня касается не только тестов. Например, сейчас я в своём статически типизированном SQL наворачиваю полный набор фичей, многие из которых могли бы и подождать, но тогда у меня не было бы ни стимула, ни понимания для того, чтобы сделать хорошую архитектуру в макросах, а так — хошь-не хошь, а приходится рефакторить снова и снова, потому что в говноархитектуру все эти фичи просто не лягут.

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, tdiff, Вы писали:
T>>Здравствуйте, __kot2, Вы писали:
__>>>отнесите ф-ию к какому-нить классу
T>>зачем?
__>я себе вообще не могу представить, чтобы я сидел такой за компом и думал "таак, мне нужен контроль компилятора за областью видимости этой функции, чтоб ее никто случайно не вызвал". что за бред вообще? голые функции остались для совместимости с Си, в современном С++ вообще об этом не надо мозг греть — все в классах должно быть по уму

ладно, бог с ней с голой. тогда объясни, как в современном с++ ограничить видимость класса? если я буду для всех приватных нетривиальных функций создавать отдельный класс, разве это будет хорошим кодом?

Здравствуйте, tdiff, Вы писали:
T>решается одна проблема, но появляется другая: теперь этот новый класс могут использовать все кому не лень, а задумывался он как приватный для конкретной задачи.
я понимаю, что мысль достаточно неочевидная и фундаментальная, поэтому приведите конкретный пример (без f и g) конкретной приватной ф-ии с конкретным классом, а я расскажу почему и как это должно быть сделано отдельным классом

Здравствуйте, __kot2, Вы писали:

__>согласен. на самом деле основная причина, по которой людей заставляют писать тесты для своего кода это то, что дерьмовый код очень сложно тестировать, поэтому они хотят-не хотят, а начинаяют разлеплять комок костылей

максимальное разлепление кусков кода вообще не означает его качественности.

Здравствуйте, tdiff, Вы писали:
T>ладно, бог с ней с голой. тогда объясни, как в современном с++ ограничить видимость класса? если я буду для всех приватных нетривиальных функций создавать отдельный класс, разве это будет хорошим кодом?
у меня был знакомый, жесткий говнарь, который писал код так:
подписывает, подписывает че-то в один класс, потом, когда он достигает нескольких тысяч строк, отрезал от него часть и начинал подписывать в обе части. он искренне полагал, что решение о том, выносить ли код в другой класс должно приниматься только на основании размера класса

на самом деле в классе вообще не должно быть ничего лишнего. класс должен быть минимален сам по себе, ну или близок к этому

Здравствуйте, tdiff, Вы писали:
T>максимальное разлепление кусков кода вообще не означает его качественности.
давайте рассмотрим на конкретном примере
мне, правда, это самому очень интересно. вдруг вы сможете привести такой пример, где это не так. но вообще слепленный код когда разлепляется, то он и проще становится и понятнее и даже, как ни странно, меньше по обьему

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, tdiff, Вы писали:
T>>максимальное разлепление кусков кода вообще не означает его качественности.
__>давайте рассмотрим на конкретном примере
__>мне, правда, это самому очень интересно. вдруг вы сможете привести такой пример, где это не так. но вообще слепленный код когда разлепляется, то он и проще становится и понятнее и даже, как ни странно, меньше по обьему

Всё хорошо в меру. А то вон авторы коллекций скалы доразлеплялись. Когда ради экономии 10 строк кода внутри методов создаётся 20 абстрактных классов... Или вот на ассемблере: кроишь-кроишь, чтобы данные поменьше места занимали, в биты их упаковываешь, а потом оказывается, что код работы с этими данными распух сильнее, чем выиграл на данных.

Здравствуйте, __kot2, Вы писали:

__>Здравствуйте, tdiff, Вы писали:
T>>решается одна проблема, но появляется другая: теперь этот новый класс могут использовать все кому не лень, а задумывался он как приватный для конкретной задачи.
__>я понимаю, что мысль достаточно неочевидная и фундаментальная, поэтому приведите конкретный пример (без f и g) конкретной приватной ф-ии с конкретным классом, а я расскажу почему и как это должно быть сделано отдельным классом


Пример из жизни: настройка виндовой службы индексирования.
По архитектуре всей системы — плагин, получающий на вход задание (Task), содержащее в себе список директорий для индексирования и для исключения из индекса.

Псевдокод варианта со свободной голой функцией:

ScopeRules CreateScopeRules(include, exclude)
{
   ScopeRules result;
   // какая-то обработка
   return result;
}

WindowsSearch : public Plugin 
{
public:
    // интерфейс Plugin
    void ProcessTask(Task t) 
    {
        auto rules = CreateScopeRules(t->include_dirs, t->exclude_dirs);
        for (const auto& rule : rules)
        {
            WindowsApiCall(rule);
        }        
    }
};

Если выделить CreateScopeRules в класс, получится:

class RulesCreator
{
    ScopeRules create(include, exclude)
    {
       ScopeRules result;
       // какая-то обработка
       return result;
    }
};

WindowsSearch : public Plugin 
{
    RulesCreator creator;
public:
    WindowsSearch(RulesCreator creator)
    {
        this->creator = creator;
    }

    // интерфейс Plugin
    void ProcessTask(Task t) 
    {
        auto rules = creator.create(t->include_dirs, t->exclude_dirs);
        for (const auto& rule : rules)
        {
            WindowsApiCall(rule);
        }        
    }
};