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

P>>Вы и сами тащите "надо проверить old и new", и другого варианта не видите, как будто его нет. Можно же и дизайн поменять, что бы юнитами такое проверять. Но нет — вы топите за моки.
·>Есть, конечно, но другие варианты хуже. Больше писать кода и сложнее тестировать.

Наоборот — юнит тесты дешевле некуда.

P>>>>У вас — охотно верю.
P>>·>Потому что у нас не хелловорды, а не как у вас, да?
P>>Потому, что вы используете дизайн, который плодит лишнее. Я вам на примере дата-время показал, как можно иначе, но вам любой пример не в вашу пользу надо забраковать.
·>По факту пока что кода лишнего больше у тебя. Притом "вот фаулер написал моки — плохо, давайте накрутим слоёв в прод коде!".

Это у вас телепатия разыгралась? С чего вы взяли, что у меня лишнего кода бОльше? У меня основной подход к разработке это как раз выбрасывать код и покрывать оставшееся максимально дешовыми юнит тестами.
Но вам конечно же виднее.

P>>Со статьё давно всё ясно. crypto api и time это пример, которые показывают, за счет можно отказаться от моков, и что будет, если этого не делать.
·>Ни для crypto api, ни для time моки не нужны обычно не потому что "дизайн", а потому что они быстрые, детерминированные, с нулём внешних зависимостей.

Вы сейчас сами себя отрицаете:
Во первых, вы сами недавно поделились решением для hmac — "моками проверим то и это"
Во вторых, чуть далее, тоже недавно, вы рассказывали, как моками отрезали Time.now

P>>Это у вас на моках упадут все тесты всех операций апи. О том и речь. А на обычных юнит-тестах вы подкидываете новый набор значений, и всё путём.
·>Почему десяток? У тебя только десяток операций в api? Откуда взялся десяток?

Десяток значений. Эти значения вы можете в каких угодно тестах использовать.

P>>·>Один, скорее всего. Ибо одного теста достаточно чтобы зафиксировать логику вычисления hmac. В остальных тестах достаточно ассертить его наличие, но не конкретный формат.
P>>"достаточно ассертить его наличие" — вот вам и привязка к "как написано"
·>Не понял. Наличие hmac — это ожидание, бизнес-требование.

Это не повод моки тащить. Если значение hmac во всех кейсах совпадает с нашим, это куда лучшая проверка. Но вместо этого вы берете моки т.к. "это бизнес-требования"

P>>Ага, тесты "как написано" Вам придется написать много больше, чем один тест — как минимум, пространство входов более-менее покрыть. Моками вы вспотеете это покрывать.
·>Я тебе показывал как надо моками покрывать.

Я про это и говорю — вы предлагаете писать мок на все случаи жизни. Как убедиться что мокируемая система совпадает по поведению с вашим моком — не ясно.

P>>Вы чего то недопоняли, но вместо уточнения начинаете валять дурака?
·>А толку уточнять. Я задал вопрос чего десяток — ответа так и не последовало.

Десяток значений, что очевидно. Что для time, что для токенов. Вот если вы тестируете свою либу date-time или hmac, там будет побольше значений, до сотни, может и больше.

P>>time api это пример дизайна, как можно уйти от комбинаторного взрыва.
·>Это не "дизайн". Это если ЯП умеет в duck typing и сооружать типы на ходу. Впрочем, тут явно фича применена не по месту.

Это никакой не duck-typing. Это статически типизированые фичи — spread и destructuring. Если какого то филда не хватает — компилятор так и скажет. Если какой то филд будет иметь не тот тип — компилятор говорит об этом.

P>>Принципиальное отличе of вместо from
·>Принципиальное отличие что тут три разных типа Date, Time и Offset — и их никак не перепутать.

Запросто — local time и server time будут все равно Time, опаньки. Есть LocalTime, AbsoluteTime, итд. Ошалеете покрывать все кейсы

·>Я предложил как решают задачу взаимодействия с неким абстрактным сложным API в тестах с моками (стабами?). То что это crypto — к сути дела не относится, я это сразу заявил в ответе на твой пример, перечитай. Так что это твои фантазии.

Вы показываете выбор в пользу моков, а не в пользу сравнения результата. Вы сами то это видите? Если у нас сотня кейсов в апи, ваш моковый подход превращается в тавтологию, тесты "как написано"
Эту самую сотню кейсов всё равно надо покрыть внятными тестами.

·>Суть в том, что компонент содержит несколько частей функциональности и весь компонент покрывается со всей его функциональностью, с моками (стабами?) зависимостей. После этого достаточно одного интеграционного теста, что несколько компонент соединились вместе и взаимодействуют хотя бы по одной части функциональности. Условно говоря, если в классе 20 методов и все 20 протестированы сотней юнит-тестов, то для тестирования интеграции обычно достаточно одного и-теста.

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

> В качестве аналогии — когда ты вставляешь CPU в материнку — тебе достаточно по сути smoke test, а не прогонять те миллионы тестов, которые были сделаны на фабрике для каждого кристалла и конденсатора.

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

·>У тебя же будет дополнительных xxxComposition на каждый метод в прод-коде и это надо будет всё как-то тестииовать в полном сборе.

Вы там похоже вовсю фантазируете.

P>>Кафка — это обычный эвент, как вариант, можно обойтись и простым юнитом, убедиться что функция возвращает объект-эвент.
P>>Если у вас такой роскоши нет — добавьте мок ровно на нотификацию, а не на кафку.
·>Так вызов метода — это и есть по сути эвент. По крайней мере, изоморфное понятие.

Эвент можно проверять как значение. А можно и моком. Значением дешевле.

P>>Проблем может быть сколько угодно, именно конечный результат говорит что правильно а что нет
·>Не знаю как у тебя, но у меня большинство ошибок именно логике в реалзиации методов, когда я тупо ошибаюсь в +1 вместо -1, from/to и т.п.

В том то и дело — и никакие моки этого не исправят. Потому и нужна проверка на результат.

P>>Здесь мы тестируем построение запроса
·>Ассерт-то в чём? Что текст запроса 'select * from users where id=?'? У тебя в тесте именно текст забит или что?

Я ж вам показал все что надо — deep equality + структура.

P>>·>Как проверить, что текст запроса хотя бы синтаксически корректен?
P>>Для этого нам всё равно придется выполнить его на реальной бд. Расскажите, как вы решите задачу вашими моками.
·>Я уже рассказывал. Интеграционным тестом repo+db. Текстов запроса в тестах нет, и быть не должно. Как-то так:

Вот видите — вам тоже нужны такие тесты Только вы предпочитаете косвенную проверку.
Кстати, как вы собираетесь пагинацию да фильтры тестировать? Подозреваю, сгенерируете несколько тысяч значений, и так для каждой таблицы?


P>>А здесь как вы моками обойдетесь?
·>Тут и не надо. Здесь же интеграция с субд тестируется. Моки (стабы?) будут дальше — в бл, в контроллере, етс.

Ну да, раз вы протащили в БЛ репозиторий, то и отрезать надо там же. А вариант сделать БЛ иначе, что бы хватило юнитов, вы отбрасываете заранее с формулировкой "по старинке надёжнее"

P>>А разве я говорил, что бд можно менять любую на любую? Построение запросов мы можем тестировать для тех бд, которые поддерживаются нами.
·>У тебя был такой код:
·>

·>const getUser = repository.getUser(id);
·>const oldUser = db.execute(getUser);
·>

·>Этот код выглядит так, что getUser выдаваемый из репы не зависит от db (и как ты заявил обещано в clean) и repo покрывается тестами независимо.

Есть такое. Они конечно же должны быть согласованы. Моя идея была в том, что бы тестировать построение запроса, а не мокать всё подряд.

·>В моём коде выше с MyRepo("connectionString") — мы тестируем только интеграцию двух частей repo + dbms. И ничего больше в таких тестах поднимать не надо.

И у меня примерно так же, только моков не будет.

P>>Что вас смущает? трансформация результата принимает ResultSet и возвращает вам нужный объект.
·>Так ведь надо не абы какой ResultSet, а именно тот, который реально возвращается из "select *". У тебя же эти по настоящему связанные сущности тестируются независимо. Что абсолютно бесполезно.

1 раз тестируются в составе интеграционного теста, такого же, как у вас. и много раз — в составе юнит-тестов, где нас интересуют подробности
— а что если в колонке пусто
— а что если значение слишком длинное
— а что если значение слишком короткое
— ...
И это в любом случае нужно делать, и никакие моки от этого не избавляют. Можно просто отказаться от таких тестов типа "у нас смок тест бд". Тоже вариант, и собственно моки здесь снова никак не помогают

P>>Расскажите, как вы это моками решите
·>Моки (стабы) — это для отпиливания зависимостей в тестах. Репу тестируем медленными и-тестами с более-менее реальной субд, а дальше моки (стабы) для быстрого тестирования всего остального.

Вот — вам надо медленными тестами тестировать репу — каждый из её методов, раз вы её присобачили. А у меня репа это фактически билдер запросов, тестируется простыми юнит-тестами.
Зато мне нужно будет несколько медленных тестов самого useCase.

P>>Это одно и то же, и в этом проблема. Я ж вам говорю, как можно иначе — но вы упорно видите только вариант из 90х-00х
·>Ты показал это "иначе", но там всё ещё хуже прибито. Вплоть до побуквенного сравнения текста sql.
—
Вы так и не рассказали, чем это хуже. Вы предложили конский запрос тестировать косвенно

P>>В новом подходе не надо БЛ прибивать ни к какой репе, ни к бд, ни к стораджу, ни к кафе, ни к внешним сервисам
·>Ага-ага.

Похоже, вам ктото запрещает посмотреть как это делается

P>>Что бы такого не случалось, в тестах должен быть сценарий, который включает возврат. И так для всех апи которые вы выставляете.
·>Не понял, если возврат отключен, то и тест должен тестировать, что возврат отключен.

Очень даже понятно — вот некто неглядя вкомитал в конфиг что возвраты отключены. Ваши действия?

·>Примерное типичное кол-во сценариев реальной системе большего, чем хоумпейдж масштаба.

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

P>>Неделя бодания и перекинули проблему наверх, только когда я сослался на федеральный закон
P>>Признавайтесь, ваша идея?
·>Только не пытайся доказать, что это у них "не работало", потому что тесты у них неправильные. Уж поверь, у них всё работало как надо (им).

После ссылки на федеральный закон вдруг "заработало" как надо.

P>>В данном случае вам нужно писать больше кода в тестах, и они будут хрупкими. Другого вы с моками не получите. Потому и убирают зависимости из БЛ целиком, что бы легче было покрывать тестами
·>Но ведь не "убирают", а переносят. Что добавляет и количество прод-кода и число тестов.

Тестов БЛ — больше, т.к. теперь можно покрывать дешовыми тестами самые разные кейсы, для того и делается.
Интеграционных — столько же, как и раньше, — по количеству АПИ и сценариев.

P>>Ага, сидим да годами ждём результаты одного теста. Вам самому не смешно?
·>Думаю ваш хоум-пейдж за час тестируется, в лучшем случае.

Полтора часа только сборка идет.

P>>А с аннотациями взял да и отрендерил манифест.
·>Гы-гы. У тебя же, ты сам говорил, что попало где попало — и в переменных окружения, и в конфигах и где угодно эти "аннотации" висят. Сваггер у вас каждые 5 минут новый, да?

Вы снова из 90х? Манифест генерируется по запросу, обычно http. Отсюда ясно, что и переменные, и конфиги, и аннотации будут учтены. Еще тенантность будет учитывать — для одного тенанта один апи доступен, для другого — другой.

·>Ты любишь сложность на пустом месте, притом в прод-коде, я уже понял. Но это плохо. Фреймворк это совсем другая весовая категория. Для того что ты пишешь достаточно extract method refactoring, а не новая архитектура с фреймворками.

Ровно наоборот. Чем проще, тем лучше. Фремворковый код он не то что бы особо сложный — просто разновидности вы будете каждый раз писать по месту. Или же отделяете, покрываете сотней тестов, и используете через аннотации без оглядки "а вдруг не сработает"