Никакой мок (стаб0 не должен нарушать инварианты, описанные в документаци.

а уже внутри из контекста - конструируются какие то типы, например с сервис локатора, или внутренней фабрики, либо на основе имеющихся данных, которые были получены путем других телодвижений.

Очень часто наш код (функция, модуль) имеют внешние зависимости. Внешняя зависимость — это все, что делает ваши тесты не правдивыми и сложно-поддерживаемыми. Файловая система — зависимость: структура каталогов может быть другой на другой машине. База данных — зависимость, ее может не быть на другой машине. Веб-сервис — зависимость: может не быть интернета или может присутствовать фаервол и.т.д

Если на вопрос: «будет ли этот компонент вести себя так же на другой машине?» вы отвечаете нет, то его необходимо “подменить” и тут вам на помощь как раз придут стабы и моки. Но есть и другая сторона медали, когда разработчик начинает увлекаться и приходит к тому, что подменяет вообще все. Соответственно тесты перестают проверять само приложение и начинают тестировать стабы, моки. Это в корне не верно. Если «живых» реализаций в тесте нет, то этот тест не тестирует ничего.

Иногда эти термины stubs и mock путают: разница в том, что стаб ничего не проверяет, а лишь имитирует заданное состояние. А мок — это объект, у которого есть ожидания. Например, что данный метод класса должен быть вызван определенное число раз. Иными словами, ваш тест никогда не сломается из-за «стаба», а вот из-за мока может.



С технической точки зрения это значит, что, используя стабы, мы проверяем состояние тестируемого класса или результат выполненного метода. При использовании мока мы проверяем, соответствуют ли ожидания мока поведению тестируемого класса. Также лучше использовать не более одного мока на тест. Иначе с высокой вероятностью вы нарушите принцип «тестировать только одну вещь». При этом, в одном тесте может быть сколько угодно стабов или же мок и стабы.

а уже внутри из контекста - конструируются какие то типы, например с сервис локатора

void testLinkToContainer()
{
    /*Тут, вместо new даже может быть Mock, который будет делать все тоже самое, кроме физического создания контейнера в системе, например как в примере создавать эксземпляр класса, напихивать в него данные, возвращать его, но не сохранять в системе*/
    IContainer* pContainer = new COrgUnit(CN, DN, Location,...);
 
    /*Тут ровно тоже самое, создается либо через mock, либо напрямую нужный класс, забивается данными*/
    IPrincipal* pPrincipal = new Personage(CN, DN, Location,...);
 
    //! Допустим через интерфейс создаем юзер аккаунт, который нужен будет для линковки
    pPrincipal->CreateUserAccountPersonage();
 
    EntityLinker* linker = new EntiryLinker(...);
 
    //! Дальше тут какие то проверки, что все засетаплено честно.
 
    //! Дальше собственно выполняем нашу линковку:
    linker->LinkToContainer(pContainer, pPrincipal);
 
   /*Дальше идет тестирование результатов линковки*/
}

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

Так что по факту и контейнер, и эта сущность, и все типы итераторов это один-единственный класс, и поэтому тестировать их отдельно друг от друга это, фактически, совмещение неприятного с бесполезным.

А то я тоже слабо представляю, что делать, если сущности оказываются сильно связанными.

Почему бы не использовать конкретные объекты, вместо моков?

Ты на все зависимые сущности моки пишешь?

Не всей системы, а только той части, которая тестируется.

Я тебе пишу про то, что ты можешь в моке не учесть, какую то вещь, которая есть в используемом классе.

На практике же, довольно часто приходится работать с довольно связанными сущностями.

Так все верно. У тебя есть три модуля, первый это Пользовател, второй Контейнер, трейти Линковщик.

Вот есть у тебя класс. Он использует какие-то объекты через интерфейсы.
Зачем в его тесте использовать какие-то конкретные объекты, а не моки? Тем более, что их вообще может не быть у тебя(например, клиент предоставляет) или они на другом уровне системы.

ЮТ и не должны(да и не могут) учитывать поведение всей системы, для этого есть другие тесты.

Моки могут быть довольно сложными.

Этот модуль.

ЮТ и не должны этим заниматься. Они проверяют работу конкретных модулей. Потому они так и называются, внезапно.

что писать паралельно какие то моки на все подряд - это излишняя, бесполезная работа?

Я если честно вот вообще не понимаю, что ты мне рассказываешь.

У тебя получается что я тестирую исключительно то, что написано в методе, не учитывая совершенно поведение системы в целом

Т.е. у меня ожидаются два каких то класса на входе, с двумя каким то методами, которые нужно вызвать, я беру мочу эти два класса у тебя в ЮТ, делая их методы пустыми, ну или возвращающими константы, и потом эти классы передаю в функцию тестирования функционала

У меня оно как то отрабатывает, но в итоге, что я протестил то?

А потом в проде, у тебя хренак, и поплыли баги со всех щелей, потому что у тебя тесты и близко не имитируют то, как работает программа.

Их будут использовать через интерфейсы. И те, кто их использует, ничего о них не знает, потому в тестах нет никакого смысла использовать эти конкретные реализации. У них есть свои ЮТ, которые проверяют корректность их работы.

Wound, видел я такие ЮТ, какие ты хочешь, которые пол системы поднимают для тестов одного модуля

Ты их будешь как то использовать? Скорее будешь. Вот и напишешь соответствующие ЮТ на их использование.

Если их убрать, то в чём пример? Приведи пример кода без тестов.

D_KEY, вот смотри

Так оно и будет протестировано. Для каждой реализации будет свой ЮТ.
Зачем тестить все реализации в тесте линкера? Он же работает через интерфейсы. В его ЮТ нужно тестить его работу.

Если у тебя несколько реализаций - обычно все нужно тестировать

Где проверять? И зачем проверять сколько раз ты что там дернул? Я не совсем понял.

Ну я уже написал, например, проверять, что дернул нужные методы нужное число раз с соответствующими аргументами.

А зачем использовать существующие классы? У них свои тесты есть. Это же модульное тестирование. Кроме того, реализаций обычно несколько, какую выбрать? Моки обычно позволяют сделать дополнительные проверки.

Я тебе привел пример, когда такой код не будет нарушением контракта.

У разных классов будут разные значения.

И, повторяю еще раз. Тесты не имеют отношения к моему примеру. Их можно вообще убрать.

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

Вот тут не понял. Зачем тебе goшные интерфейсый в java?

Это будет ближе к практике?

С чего ты взял, что у него такой контракт?

Да не реализует он другой контракт. Ты, по-моему, на ходу выдумываешь.

либо класс B не является наследником класса A, т.к. реализует другой контракт, либо контракт в тесте описан некорректно.

В результате, теперь в случае экземпляра B, выводиться будет A.

Зачем их создавать, если у тебя есть возможность уже использовать существующие классы например?

Зачем их создавать, если у тебя есть возможность уже использовать существующие классы например?

А ты часто видишь, чтобы кто-то явно кастил к базовому классу?

Во-вторых, я мало видел тестов, где бы кастили к базовому классу. Возможно, все кастят, а мне попадалось говно. Но это ничего на самом деле не меняет.

Создам два mock'а, свяжу, проверю связь. Если нужно, чтоб дергались методы интерфейсов, проверю, что дергается нужное число раз и с ожидаемыми параметрами(gmock это позволяет).

меня интересует как ты будешь тестить линкер

Нет. Тесты будут разные на все три класса. Линкер твой вообще не будет знать ничего про конкретные классы и в его тестах вместо них будут mock-объекты, реализующие IContainer и IPrincipal, соответственно.

...
Верно?

А если тебе до линковки нужно будет вызвать какой нибудь метод, который есть в базовом классе IContainer/IPrincipal, но нет в том, который ты пытаешься протестить?

Ты пишешь тест на класс. Что значит никто не тестит через классы? Покажи плиз свой обычный тест на класс.

Wound, я не понимаю тебя, извини.

Именно. В результате у тебя при тесте конкретного класса другие конкретные классы, как правило, не задействованы. Вместо них у тебя будет mock- объект с нужным интерфейсом.
"I

Практически постоянно вижу, что работают все через интерфейсы. Через классы вообще мало кто работает.

Mock-объекты нужны для имитации того, что ты не можешь иметь в ЮТ. Допустим - это может быть БД, Флешка, какое то устройство, еще чего то, какой нибудь контекст, который получается путем сложных манипуляций и т.д.

А ты часто видишь, чтобы кто-то явно кастил к базовому классу?

А ты тестируешь наследование?

Чего? Mock-объекты и нужны для тестов.

Нет, тестируемый класс как раз не Mock. А все его окружение, которое в реальном коде будет реальными объектами, в тестах сделано через Mock-объекты.

В моем примере в других тестах(не A и не B), вместо реальных объектов было бы Mock-объект, наследованный от A:

Ну вся фишка в том, что в твоем случае не тестируется дин. полиморфизм.

Хотя по факту у тебя там наследование, которое ты не тестируешь.

Допустим в явошарпах, там тестируется буквально все, моки там нужны разве что для объектов, которые невозможно съэмитировать с помощью тестов.

У тебя будет Mock-Объект, вместо тестируемого класса? :-?

Да как он у тебя выплывет? Класс B тестируется только в юнит-тесте класса B. В остальных юнит-тестах будет mock-объект вместо реального.

А они как бы все в язык несут, все новомодности модные собирают со всех языков и несут в язык. Чтоб было. :D

Пишешь ЮТ - которые эмулируют работу, с помощью тех же mock объектов. Как правило помимо самих функций - тестируется еще и функционал который они делают. Потому как в 99% случаев, бывает такое, что для того, что бы юзнуть функцию в ЮТ, для нее нужно настроить окружение. А это подразумевает имитирование работы части функционала.

Например там функция ждет от тебя какой нибудь коннектор, провайдер, поток с данными и т.д. чтоб дальше с ним работать, или например еще что то, и а те в свою очередь, для того чтоб вернули ожидаемые значения могут еще что то принимать, что в свою очередь может принимать еще другое. И в итоге ты начинаешь делать mock объекты и эмулировать работу программы в ЮТ.

Где практически все косяки, в том числе и те, которые ты написал зачастую всплывают.

Потому что это всего-лишь пример. Иллюстрация.
Ты не всегда сможешь отследить изменение сигнатуры в реальном проекте.

А для чего добавили, на твой взгляд?

Во-первых, ЮТ не являются частью языка. Во-вторых, я мало видел тестов, где бы кастили к базовому классу. Возможно, все кастят, а мне попадалось говно. Но это ничего на самом деле не меняет.

Тебе объясняют почему в принципе не нужен override, а ты объясняешь от чего он спасает. Так если не писать так, как ты показал - то нафиг этот override нужен то? :D

Между прочим в С++ override появился сравнительно недавно. И до него как то не особо припомню вот таких вот проблем.

Обычно все разруливалось ЮТ.

А причём тут вообще проектирование? override ему ортогонален совершенно.

Это уже совсем из другой области вопрос.

Но использование его, еще не означает что ты проектируешь систему правильно.

И раз у тебя возникают такие ошибки, и тебе помог override, значит скорее всего будут и другие ошибки, на которые синтаксического сахара не найдется.

потому что надо писать вот так то и так то

Зачем это всё? Чтобы лучше всё структурировать вместо каши из override и non-override методов, чтобы IDE лучше понимала семантику кода, в частности выполняла семантически более точный рефакторинг при изменении сигнатуры методов «родителей», который мы тут обсуждали. + один набор юнит-тестов на разные реализации. И при этом добавить некоторую гибкость в виде протоколов. Хз как там в ваших D/Rust/C#, но без аналога Go'шных интерфейсов или OCaml'овских object type'ов в Java грустновато.

Работу класса я тестирую.

У тебя в твоем примере тесты отличаются от реальной работы классов. Т.е. тесты живут своей жизнью, программа живет своей жизнью. Не совсем понятно что ты тестишь.

Раз ты у себя в коде пишешь:

Значит это же у тебя должно быть и в тестах

И часто ты в тестах такой каст делаешь?

   

присвоей его переменной базового класса А.

И его тест

Все ок, если создадим экземпляр B, то будет выведено "B".

Зачем это всё? Чтобы лучше всё структурировать вместо каши из override и non-override методов, чтобы IDE лучше понимала семантику кода, в частности выполняла семантически более точный рефакторинг при изменении сигнатуры методов «родителей», который мы тут обсуждали. + один набор юнит-тестов на разные реализации. И при этом добавить некоторую гибкость в виде протоколов.

Хз как там в ваших D/Rust/C#, но без аналога Go'шных интерфейсов или OCaml'овских object type'ов в Java грустновато.

Но это только интерфейсы, осталось разобрать наследование реализаций (классов)…

И, внезапно, если бы там был override, то компилятор бы ругался и никакой проблемы бы не возникло.

error: ‘std::__cxx11::string B::foo() const’ marked ‘override’, but does not override
std::string foo() const override

Включил. И они проходят, потому что теперь тестируют методы нового класса.

Они же, вероятно, как раз дергают методы класса, который тестируют, а не базового класса, и это нормально. И такие тесты будут продолжать проходить.