Сообщение Re[35]: Что такое Dependency Rejection от 01.01.2024 10:09
Изменено 01.01.2024 11:49 Pauel
Re[35]: Что такое Dependency Rejection
Здравствуйте, ·, Вы писали:
>>> Твои "{...toFields}" — тоже лишний код, и это всё прод-код.". Ты только от первого открестился, а на вторые два сделал вид, что их не было.
P>>{...toFields} экономит вам десяток другой методов и тестов для них. Если у вас нет такого метода, вам придется или по месту колбасить код, намного больше, или создавать все возможные методы для конверсии.
·>Не экономит. Конкретные типы и конструкторы с ними соответствуют конкретным арифметическим операциям с календарём. Твоё toFields — какое-то месиво, неясно о чём и чревато багами. Скажем, если у тебя тип time окажется какого-то не того типа, то эта твоя ... начнёт давать странное месиво с неясным результатом из=за перекрытия одноимённых полей. Не надо так делать.
Ваша альтернатива — понасоздавать вагон методов для конверсии "всё во всё" что дает вагон кода и вагон тестов. Или же вместо однострочной конверсии у вас будет несколько строчек кода точно так же без полного контроля.
P>>Потому, что одного теста на моках, как вы показываете, недостаточно. Вам придется вместо таблицы инстинности приседать с моками.
·>Недостаточно для чего? Почему недостаточно? Причём тут таблица истинности?
Логику, вычисления мы тестируем по таблице истинности. И чем меньше дополнительного кода сверх этой таблицы истинности, тем лучше. А вам надо все поразмазывать по мокам
P>>Вы уже показали — кода в тестах в вашем исполнении больше.
·>Больше, т.к. код делает больше.
Функционально — ровно столько же.
P>>У вас какая то мешанина — интерграционные это все что выше юнитов. Сценарии — это на самом верху, уровень приложения или всей системы. Не ясно, за счет чего у вас будет меньше интеграционных — похоже, вы верите, что моки здесь чего то решают.
·>Меньше интеграционных за счёт того, что они тестируют интеграцию. А не всю копипасту, которую ты предлагаешь плодить.
Моки не тестируют интеграцию. Моком вы можете проверить, а что будет, если подкинуть ту или иную зависимость. А нам надо совсем другое — готовый компонент работает как нам надо.
Это разные вещи и вы продолжаете путать.
Количество интеграционных тестов моки уменьшить никак не могут. Моки — это фактически понижение уровня тестирования за счет обрезания зависимостей. Нам же надо не понижение, а повышение.
P>>Это ж не значит, что и применять данных подход нужно везде. В некоторых интеграционных тестах, которых обычно немного.
·>Как немного? Ты пишешь по интеграционному тесту для каждого do_logic. Т.к. именно там происходит склейка.
Есть метод — его нужно вызвать в тестах. И у вас будет ровно то же. Просто вас тянет тестировать код, а не ожидания вызывающей стороны.
Склейка или нет дело десятое — вызывающая сторона никаких ожиданий на этот счет не имеет, ей про это неизвестно.
Проверка конкретной склейки — это вайтбокс, тест "как написано", классика тавтологии.
Вместо проверки конкретной склейки делаем интеграционный код линейным, буквально, а интеграцию осуществляем на самом верху.
P>>deep equals проверяет значение, всё разом, если у вас чтото больше чем инт или строка
·>Я знаю. И это плохо, особенно для юнит-тестов.
Простите, вы мапперы из одной структуры в другую как тестировать собираетесь?
P>>Поломаются тесты не там, где вы обмокали, а ровно по месту — меняется таблица истинности функции
·>Так функция может использоваться из множества мест.
Пусть используется. Что вас смущает ?
P>>В вашем случае далеко не факт, что найдете в моках все нужные места, и сделаете что бы соответствовало
·>Какие места? Зачем их искать?
Читайте себя "Так функция может использоваться из множества мест."
У вас в тех самых тестах все будет обмокано. Как узнаете, что там, в моках, должно вызываться не "то", а "это"?
P>>Если у вас будет подсчет статистики, вы вспотеете покрывать тестами "из базы"
·>Ты потерял контекст. Тут шла речь о ю-тест упоминал "а что если в колонке пусто". В колонке, внезапно окажется, будет не пусто а дефолтное значение из бд. Багу такую поймаешь только на проде, т.к. и-тесты для таких подробных мелочей явно писать не будешь.
Наоборот — именно для таких мелочей юнит-тесты и нужны.
·>Я эту багу поймаю на и-тесте repo+dbms — пытаясь воспроизвести пустую колонку.
Вы пытаетесь таблицу истинности запихать куда подальше, в данном случае в бд. А она должна быть прямо рядом с тестом как можно ближе к коду.
Что там будет с бд, когда другой девелопер чего нибудь фиксанет — а хрен его знает.
А если таблица истинности рядом с тестами и тестируемой функцией, шансов намного больше что проблему заметят еще во время код ревью.
P>>Не дополнительными, а теми же самыми интеграционными, что есть и у вас. Интеграционные тесты не пишутся на все вещи вида "проверим что где то внутре передается параметр". Если такое критично — выносится в юниты.
·>Ты не в тему споришь. Ты заявил "Интеграционный тест проверяет 1) что сама склейка валидная". Мест склейки now и nextFriday(now) у тебя будет полно. У меня такое место — одно.
Интеграционный тест проверяет всю интеграцию разом, а вас тянет проверить каждую строчку. Каждая строчка — это про юнит-тестирование.
P>>Если у нас код контролера линейный, а в моем случае это именно так, то нам нужен ровно один интеграционный тест, который нужен и вам
·>_Такой_ интеграционный тест мне не нужен. Я могу обойтись одним ю-тестом с моком о том, что nextFriday() действительно возвращает правильные даты для разных моментов времени. И ещё соответсвующими ю-тестами в местах использования nextFriday(), там можно моком просто возвращать хоть семь пятниц на неделе.
Какой такой? Вам всё равно нужен интеграционный тест. Задачи интеграционных тестов не каждую склейку проверять по отдельности, а проверять работает ли компонент собраный целиком. Что там унутре — для интеграционного тестирования по барабану — нужная функция работает, значит всё хорошо.
P>>Никак.
·>Именно. Т.е. усложняешь прод-код, теряешь возможность протестировать и ловишь баги в проде. Нам такого не надо.
Забавная телепатия.
P>>У вас причин для изменения гораздо больше — любое измение дизайна означает поломку ваших тестов на моках.
·>Это страшилки.
Это следует из ваших примеров.
·>Мде. Если хочешь строчки считать по честному, показывай изменения в прод коде и тест на каждый вызов nextFriday.
Тест на каждый вызов это классика тавтологичного тестирования
P>>ок — на 4.
·>Я тоже так умею:
·>
·>Сейчас начнёшь символы считать, да?
Обычное правило — 1 инструкция на строку. Вы втюхали минимум две. А поскольку у вас значения захардкожены, то между разными тестами согласованность никак не проверяется, т.к. везде хардкодите значения.
P>>Смотрите выше — я вас просил хороший вариант тестирования кода с hmac. Вы во второй раз показали моки, хотя и сами пишете, что так делать не надо.
·>А что там хочешь увидеть, я не понял. Для каждого теста hmac будет известным и фиксированным. Ассертишь по значению, да и всё.
Ну ок.
P>>И не собираюсь — data complexity решается совсем другими инструментами. Количество перестановок в фильтрах спокойно может исчисляться чудовищным количеством кейсов. Если некто поправит запрос, и забудет нагенерерить сотню другую данных — приплыли.
·>Именно. Так что неясно зачем ты делаешь эти предъявы о гарантиях. У тебя аргументация вида "Раз ваш подход не умеет кофе варить и тапочки приносить — значит это плохо и надо делать как фаулер завещал".
Вы забыли, что именно вы претендуете что решите это всё тестами.
P>>т.е. вы снова притягиваете решение которое зависит от человеческого фактора
·>А у тебя есть решение независящее от человеческого фактора?
Его можно ограничить контролируя построение запроса + таблицу истинности храним не абы где, а рядом. Вы же все хотите таблицу истинности или размазать, или запихать куда подальше.
P>>тот самый интеграционный тест, на некорретном запросе он упадет
·>Т.е. у тебя интеграционные тесты будет тестировать всё "чудовищное количество кейсов"? Накой тогда ю-тесты?
Интеграционные тесты не проверяют варианты склейки — они проверяют функционирование в сборе. Юнит-тесты проверяют работоспособность примитивов.
·>Я это знаю из тригонометрии, от моего кода не зависящей. А вот то, что fn2 — правильно, а fn3 — неправильно ты знаешь только из "как в коде написано". Т.е. твой код тестирует самого себя, порочный круг
называется.
Не из кода, а из требований вызывающей стороны.
P>>fn1 и fn2 должны быть видны в тестах, а не публично
·>А тесты должны, по уму, тестировать публичный контракт. @VisibleForTesting — это очень хороший сигнал code smells.
Это ваша фантазия — эдак у вас юнит-тесты станут code smell, тк они принципиально по своей сути видят слишком много.
P>>Тем, что у вас в тестовой бд может не оказаться тех самых значений, которые ломают один из сотен-тысяч кейсов
·>И у вас в тестах может не оказаться тех самых значений для построения того самого ломающего запроса. Опять "тапочки не приносит"?
В моем случае таблица истинности рядом с тестом и функцией. Вы же ее пихаете куда подальше — прямо в бд.
Скажите честно — у вас есть требование по процессу во время код ревью обязательно смотреть содержимое тестовой бд? Те самые десятки-сотни-тысячи записей
P>>Для этого вам надо перебрать все возможные сочетания фильтров -> здесь счет тестов идет на десятки тысяч по скромной оценке
·>Нам — не надо.
Вероятно, это особенность вашего проекта. Любая более-менее внятная статистика-аналитика по бд это довольно сложные алгоритмы, и здесь нужно чтото лучше, чем смотреть в бд и думать, что же должно быть на выходе.
P>>Выборочные тесты. Поскольку я знаю, как строятся фильтры, мне нужно убедиться, что они таки вызываются. И не надо проверять всё перестановки.
·>Ага. Именно то самое whitebox, котором ты ещё недавно меня попрекал.
Раскройте глаза — здесь блекбокс. Выборочно вызываем бд нашим кодом, проверяется весь пайплайн в сборе, косвенно. Только нам не надо проверять всё на свете таким образом, т.к. есть и другие инструменты.
P>>И вы уверены, что в тестовой бд всегда будет полный фарш? Вы что, один работаете?
·>"Тапочки не приносит".
Вы никак не можете объяснить преимущества размазывания таблицы истинности по тестами и бд, чем это лучше хранения таблицы истинности рядом с кодом и функцией с тестом.
P>>Противоречие у вас в голове. Сказано — полного контроля не дают.
·>Именно. Зачем же тогда покрыть юнит-тестами?
—
Затем, что доказательство корректности — это необходимое условие. А такое доказательство + тесты + код ревью, необходимое и достаточное.
P>>·>Как доказывать корректность запроса?
P>>Да как обычно это делается с алгоритмами.
·>И что мешает это же делать в repo+dbms?
Вы же сами говорите,что про это не думаете, верите только в результаты. Вот вы и нашли, кто мешает.
P>>Откуда у вас знание "слишком" или "не слишком" ? Вы даже не в курсе, что за проект, но делаете какие то суждения. Для того проекта — нет, не слишком.
·>Это значит, что изменение в коде занимает как минимум день для выкатки в прод. Значит глобально архитектура выбрана плохо. Возможно надо резать на независимые компоненты.
Нет, не значит.
Вы не в курсе, ни что за проект, ни какие требования, итд. Далеко не все проекты могут протаскивать изменения в прод прям сразу.
Во вторых, я вам сказал, что это полная сборка, все платформы, всё-всё-всё. Кто вам сказал, что нет сборки отдельных модулей?
И так у вас всё — вместо вопросов занимаетесь телепатией.
P>>Переписывать то зачем? Чем они вам мешают?
·>Тем, что они написаны на конкретном ЯП.
Я ж сказал — если по аннотации можно сгенерировать 4 артефакта, то почему нельзя сгенерировать 5й, 6й, 7й?
Вы же видите только переписывание
P>>·>Смотря как долго проект живёт.
P>>Чем дольше, тем меньше шансов на переписывание, проще заново напилить новое.
·>Но при сохранении контракта, который у вас описан на аннотациях конкретного ЯП. В общем гугли ликбез, например, тут https://swagger.io/blog/code-first-vs-design-first-api/
Вы путаете code-first и design-first. design first — означает, что первое деливери это апи, а не реализация. code-first — наоборот. А какой файл вы в начале редактируете, json или java и yaml, дело десяток
Я ж сразу сказал — апи уже есть, а реализации нету, зато можно и тесты писать, и клиентский код, и документацию прикручивать
>>> Твои "{...toFields}" — тоже лишний код, и это всё прод-код.". Ты только от первого открестился, а на вторые два сделал вид, что их не было.
P>>{...toFields} экономит вам десяток другой методов и тестов для них. Если у вас нет такого метода, вам придется или по месту колбасить код, намного больше, или создавать все возможные методы для конверсии.
·>Не экономит. Конкретные типы и конструкторы с ними соответствуют конкретным арифметическим операциям с календарём. Твоё toFields — какое-то месиво, неясно о чём и чревато багами. Скажем, если у тебя тип time окажется какого-то не того типа, то эта твоя ... начнёт давать странное месиво с неясным результатом из=за перекрытия одноимённых полей. Не надо так делать.
Ваша альтернатива — понасоздавать вагон методов для конверсии "всё во всё" что дает вагон кода и вагон тестов. Или же вместо однострочной конверсии у вас будет несколько строчек кода точно так же без полного контроля.
P>>Потому, что одного теста на моках, как вы показываете, недостаточно. Вам придется вместо таблицы инстинности приседать с моками.
·>Недостаточно для чего? Почему недостаточно? Причём тут таблица истинности?
Логику, вычисления мы тестируем по таблице истинности. И чем меньше дополнительного кода сверх этой таблицы истинности, тем лучше. А вам надо все поразмазывать по мокам
P>>Вы уже показали — кода в тестах в вашем исполнении больше.
·>Больше, т.к. код делает больше.
Функционально — ровно столько же.
P>>У вас какая то мешанина — интерграционные это все что выше юнитов. Сценарии — это на самом верху, уровень приложения или всей системы. Не ясно, за счет чего у вас будет меньше интеграционных — похоже, вы верите, что моки здесь чего то решают.
·>Меньше интеграционных за счёт того, что они тестируют интеграцию. А не всю копипасту, которую ты предлагаешь плодить.
Моки не тестируют интеграцию. Моком вы можете проверить, а что будет, если подкинуть ту или иную зависимость. А нам надо совсем другое — готовый компонент работает как нам надо.
Это разные вещи и вы продолжаете путать.
Количество интеграционных тестов моки уменьшить никак не могут. Моки — это фактически понижение уровня тестирования за счет обрезания зависимостей. Нам же надо не понижение, а повышение.
P>>Это ж не значит, что и применять данных подход нужно везде. В некоторых интеграционных тестах, которых обычно немного.
·>Как немного? Ты пишешь по интеграционному тесту для каждого do_logic. Т.к. именно там происходит склейка.
Есть метод — его нужно вызвать в тестах. И у вас будет ровно то же. Просто вас тянет тестировать код, а не ожидания вызывающей стороны.
Склейка или нет дело десятое — вызывающая сторона никаких ожиданий на этот счет не имеет, ей про это неизвестно.
Проверка конкретной склейки — это вайтбокс, тест "как написано", классика тавтологии.
Вместо проверки конкретной склейки делаем интеграционный код линейным, буквально, а интеграцию осуществляем на самом верху.
P>>deep equals проверяет значение, всё разом, если у вас чтото больше чем инт или строка
·>Я знаю. И это плохо, особенно для юнит-тестов.
Простите, вы мапперы из одной структуры в другую как тестировать собираетесь?
P>>Поломаются тесты не там, где вы обмокали, а ровно по месту — меняется таблица истинности функции
·>Так функция может использоваться из множества мест.
Пусть используется. Что вас смущает ?
P>>В вашем случае далеко не факт, что найдете в моках все нужные места, и сделаете что бы соответствовало
·>Какие места? Зачем их искать?
Читайте себя "Так функция может использоваться из множества мест."
У вас в тех самых тестах все будет обмокано. Как узнаете, что там, в моках, должно вызываться не "то", а "это"?
P>>Если у вас будет подсчет статистики, вы вспотеете покрывать тестами "из базы"
·>Ты потерял контекст. Тут шла речь о ю-тест упоминал "а что если в колонке пусто". В колонке, внезапно окажется, будет не пусто а дефолтное значение из бд. Багу такую поймаешь только на проде, т.к. и-тесты для таких подробных мелочей явно писать не будешь.
Наоборот — именно для таких мелочей юнит-тесты и нужны.
·>Я эту багу поймаю на и-тесте repo+dbms — пытаясь воспроизвести пустую колонку.
Вы пытаетесь таблицу истинности запихать куда подальше, в данном случае в бд. А она должна быть прямо рядом с тестом как можно ближе к коду.
Что там будет с бд, когда другой девелопер чего нибудь фиксанет — а хрен его знает.
А если таблица истинности рядом с тестами и тестируемой функцией, шансов намного больше что проблему заметят еще во время код ревью.
P>>Не дополнительными, а теми же самыми интеграционными, что есть и у вас. Интеграционные тесты не пишутся на все вещи вида "проверим что где то внутре передается параметр". Если такое критично — выносится в юниты.
·>Ты не в тему споришь. Ты заявил "Интеграционный тест проверяет 1) что сама склейка валидная". Мест склейки now и nextFriday(now) у тебя будет полно. У меня такое место — одно.
Интеграционный тест проверяет всю интеграцию разом, а вас тянет проверить каждую строчку. Каждая строчка — это про юнит-тестирование.
P>>Если у нас код контролера линейный, а в моем случае это именно так, то нам нужен ровно один интеграционный тест, который нужен и вам
·>_Такой_ интеграционный тест мне не нужен. Я могу обойтись одним ю-тестом с моком о том, что nextFriday() действительно возвращает правильные даты для разных моментов времени. И ещё соответсвующими ю-тестами в местах использования nextFriday(), там можно моком просто возвращать хоть семь пятниц на неделе.
Какой такой? Вам всё равно нужен интеграционный тест. Задачи интеграционных тестов не каждую склейку проверять по отдельности, а проверять работает ли компонент собраный целиком. Что там унутре — для интеграционного тестирования по барабану — нужная функция работает, значит всё хорошо.
P>>Никак.
·>Именно. Т.е. усложняешь прод-код, теряешь возможность протестировать и ловишь баги в проде. Нам такого не надо.
Забавная телепатия.
P>>У вас причин для изменения гораздо больше — любое измение дизайна означает поломку ваших тестов на моках.
·>Это страшилки.
Это следует из ваших примеров.
·>Мде. Если хочешь строчки считать по честному, показывай изменения в прод коде и тест на каждый вызов nextFriday.
Тест на каждый вызов это классика тавтологичного тестирования
P>>ок — на 4.
·>Я тоже так умею:
·>
·>var clock = mock(InstantSource.class);
·>var testSubject = new CalendarLogic(clock);
·>when(clock.instant()).thenReturn(Instant.of("2023-12-28T12:27:00Z"));assertThat(testSubject.nextFriday()).equalTo(LocalDate.of("2023-12-29"));
·>when(clock.instant()).thenReturn(Instant.of("2023-12-29T23:59:59Z"));assertThat(testSubject.nextFriday()).equalTo(LocalDate.of("2023-12-29"));
·>when(clock.instant()).thenReturn(Instant.of("2023-12-30T00:00:00Z"));assertThat(testSubject.nextFriday()).equalTo(LocalDate.of("2024-01-05"));
·>·>Сейчас начнёшь символы считать, да?
Обычное правило — 1 инструкция на строку. Вы втюхали минимум две. А поскольку у вас значения захардкожены, то между разными тестами согласованность никак не проверяется, т.к. везде хардкодите значения.
P>>Смотрите выше — я вас просил хороший вариант тестирования кода с hmac. Вы во второй раз показали моки, хотя и сами пишете, что так делать не надо.
·>А что там хочешь увидеть, я не понял. Для каждого теста hmac будет известным и фиксированным. Ассертишь по значению, да и всё.
Ну ок.
P>>И не собираюсь — data complexity решается совсем другими инструментами. Количество перестановок в фильтрах спокойно может исчисляться чудовищным количеством кейсов. Если некто поправит запрос, и забудет нагенерерить сотню другую данных — приплыли.
·>Именно. Так что неясно зачем ты делаешь эти предъявы о гарантиях. У тебя аргументация вида "Раз ваш подход не умеет кофе варить и тапочки приносить — значит это плохо и надо делать как фаулер завещал".
Вы забыли, что именно вы претендуете что решите это всё тестами.
P>>т.е. вы снова притягиваете решение которое зависит от человеческого фактора
·>А у тебя есть решение независящее от человеческого фактора?
Его можно ограничить контролируя построение запроса + таблицу истинности храним не абы где, а рядом. Вы же все хотите таблицу истинности или размазать, или запихать куда подальше.
P>>тот самый интеграционный тест, на некорретном запросе он упадет
·>Т.е. у тебя интеграционные тесты будет тестировать всё "чудовищное количество кейсов"? Накой тогда ю-тесты?
Интеграционные тесты не проверяют варианты склейки — они проверяют функционирование в сборе. Юнит-тесты проверяют работоспособность примитивов.
·>Я это знаю из тригонометрии, от моего кода не зависящей. А вот то, что fn2 — правильно, а fn3 — неправильно ты знаешь только из "как в коде написано". Т.е. твой код тестирует самого себя, порочный круг
называется.
Не из кода, а из требований вызывающей стороны.
P>>fn1 и fn2 должны быть видны в тестах, а не публично
·>А тесты должны, по уму, тестировать публичный контракт. @VisibleForTesting — это очень хороший сигнал code smells.
Это ваша фантазия — эдак у вас юнит-тесты станут code smell, тк они принципиально по своей сути видят слишком много.
P>>Тем, что у вас в тестовой бд может не оказаться тех самых значений, которые ломают один из сотен-тысяч кейсов
·>И у вас в тестах может не оказаться тех самых значений для построения того самого ломающего запроса. Опять "тапочки не приносит"?
В моем случае таблица истинности рядом с тестом и функцией. Вы же ее пихаете куда подальше — прямо в бд.
Скажите честно — у вас есть требование по процессу во время код ревью обязательно смотреть содержимое тестовой бд? Те самые десятки-сотни-тысячи записей
P>>Для этого вам надо перебрать все возможные сочетания фильтров -> здесь счет тестов идет на десятки тысяч по скромной оценке
·>Нам — не надо.
Вероятно, это особенность вашего проекта. Любая более-менее внятная статистика-аналитика по бд это довольно сложные алгоритмы, и здесь нужно чтото лучше, чем смотреть в бд и думать, что же должно быть на выходе.
P>>Выборочные тесты. Поскольку я знаю, как строятся фильтры, мне нужно убедиться, что они таки вызываются. И не надо проверять всё перестановки.
·>Ага. Именно то самое whitebox, котором ты ещё недавно меня попрекал.
Раскройте глаза — здесь блекбокс. Выборочно вызываем бд нашим кодом, проверяется весь пайплайн в сборе, косвенно. Только нам не надо проверять всё на свете таким образом, т.к. есть и другие инструменты.
P>>И вы уверены, что в тестовой бд всегда будет полный фарш? Вы что, один работаете?
·>"Тапочки не приносит".
Вы никак не можете объяснить преимущества размазывания таблицы истинности по тестами и бд, чем это лучше хранения таблицы истинности рядом с кодом и функцией с тестом.
P>>Противоречие у вас в голове. Сказано — полного контроля не дают.
·>Именно. Зачем же тогда покрыть юнит-тестами?
—
Затем, что доказательство корректности — это необходимое условие. А такое доказательство + тесты + код ревью, необходимое и достаточное.
P>>·>Как доказывать корректность запроса?
P>>Да как обычно это делается с алгоритмами.
·>И что мешает это же делать в repo+dbms?
Вы же сами говорите,что про это не думаете, верите только в результаты. Вот вы и нашли, кто мешает.
P>>Откуда у вас знание "слишком" или "не слишком" ? Вы даже не в курсе, что за проект, но делаете какие то суждения. Для того проекта — нет, не слишком.
·>Это значит, что изменение в коде занимает как минимум день для выкатки в прод. Значит глобально архитектура выбрана плохо. Возможно надо резать на независимые компоненты.
Нет, не значит.
Вы не в курсе, ни что за проект, ни какие требования, итд. Далеко не все проекты могут протаскивать изменения в прод прям сразу.
Во вторых, я вам сказал, что это полная сборка, все платформы, всё-всё-всё. Кто вам сказал, что нет сборки отдельных модулей?
И так у вас всё — вместо вопросов занимаетесь телепатией.
P>>Переписывать то зачем? Чем они вам мешают?
·>Тем, что они написаны на конкретном ЯП.
Я ж сказал — если по аннотации можно сгенерировать 4 артефакта, то почему нельзя сгенерировать 5й, 6й, 7й?
Вы же видите только переписывание
P>>·>Смотря как долго проект живёт.
P>>Чем дольше, тем меньше шансов на переписывание, проще заново напилить новое.
·>Но при сохранении контракта, который у вас описан на аннотациях конкретного ЯП. В общем гугли ликбез, например, тут https://swagger.io/blog/code-first-vs-design-first-api/
Вы путаете code-first и design-first. design first — означает, что первое деливери это апи, а не реализация. code-first — наоборот. А какой файл вы в начале редактируете, json или java и yaml, дело десяток
Я ж сразу сказал — апи уже есть, а реализации нету, зато можно и тесты писать, и клиентский код, и документацию прикручивать
Re[35]: Что такое Dependency Rejection
Здравствуйте, ·, Вы писали:
>>> Твои "{...toFields}" — тоже лишний код, и это всё прод-код.". Ты только от первого открестился, а на вторые два сделал вид, что их не было.
P>>{...toFields} экономит вам десяток другой методов и тестов для них. Если у вас нет такого метода, вам придется или по месту колбасить код, намного больше, или создавать все возможные методы для конверсии.
·>Не экономит. Конкретные типы и конструкторы с ними соответствуют конкретным арифметическим операциям с календарём. Твоё toFields — какое-то месиво, неясно о чём и чревато багами. Скажем, если у тебя тип time окажется какого-то не того типа, то эта твоя ... начнёт давать странное месиво с неясным результатом из=за перекрытия одноимённых полей. Не надо так делать.
Ваша альтернатива — понасоздавать вагон методов для конверсии "всё во всё" что дает вагон кода и вагон тестов. Или же вместо однострочной конверсии у вас будет несколько строчек кода точно так же без полного контроля.
P>>Потому, что одного теста на моках, как вы показываете, недостаточно. Вам придется вместо таблицы инстинности приседать с моками.
·>Недостаточно для чего? Почему недостаточно? Причём тут таблица истинности?
Логику, вычисления мы тестируем по таблице истинности. И чем меньше дополнительного кода сверх этой таблицы истинности, тем лучше. А вам надо все поразмазывать по мокам
P>>Вы уже показали — кода в тестах в вашем исполнении больше.
·>Больше, т.к. код делает больше.
Функционально — ровно столько же.
P>>У вас какая то мешанина — интерграционные это все что выше юнитов. Сценарии — это на самом верху, уровень приложения или всей системы. Не ясно, за счет чего у вас будет меньше интеграционных — похоже, вы верите, что моки здесь чего то решают.
·>Меньше интеграционных за счёт того, что они тестируют интеграцию. А не всю копипасту, которую ты предлагаешь плодить.
Моки не тестируют интеграцию. Моком вы можете проверить, а что будет, если подкинуть ту или иную зависимость. А нам надо совсем другое — готовый компонент работает как нам надо.
Это разные вещи и вы продолжаете путать.
Количество интеграционных тестов моки уменьшить никак не могут. Моки — это фактически понижение уровня тестирования за счет обрезания зависимостей. Нам же надо не понижение, а повышение.
P>>Это ж не значит, что и применять данных подход нужно везде. В некоторых интеграционных тестах, которых обычно немного.
·>Как немного? Ты пишешь по интеграционному тесту для каждого do_logic. Т.к. именно там происходит склейка.
Есть метод — его нужно вызвать в тестах. И у вас будет ровно то же. Просто вас тянет тестировать код, а не ожидания вызывающей стороны.
Склейка или нет дело десятое — вызывающая сторона никаких ожиданий на этот счет не имеет, ей про это неизвестно.
Проверка конкретной склейки — это вайтбокс, тест "как написано", классика тавтологии.
Вместо проверки конкретной склейки делаем интеграционный код линейным, буквально, а интеграцию осуществляем на самом верху.
P>>deep equals проверяет значение, всё разом, если у вас чтото больше чем инт или строка
·>Я знаю. И это плохо, особенно для юнит-тестов.
Простите, вы мапперы из одной структуры в другую как тестировать собираетесь? А парсинг? А как вы проверите, что ваш репозиторий на конкретный запрос вернет ту самую структуру? Например, нам нужен order + order items + customer + delivery + billing
Как вы собираетесь протестировать результат?
P>>Поломаются тесты не там, где вы обмокали, а ровно по месту — меняется таблица истинности функции
·>Так функция может использоваться из множества мест.
Пусть используется. Что вас смущает ?
P>>В вашем случае далеко не факт, что найдете в моках все нужные места, и сделаете что бы соответствовало
·>Какие места? Зачем их искать?
Читайте себя "Так функция может использоваться из множества мест."
У вас в тех самых тестах все будет обмокано. Как узнаете, что там, в моках, должно вызываться не "то", а "это"?
P>>Если у вас будет подсчет статистики, вы вспотеете покрывать тестами "из базы"
·>Ты потерял контекст. Тут шла речь о ю-тест упоминал "а что если в колонке пусто". В колонке, внезапно окажется, будет не пусто а дефолтное значение из бд. Багу такую поймаешь только на проде, т.к. и-тесты для таких подробных мелочей явно писать не будешь.
Наоборот — именно для таких мелочей юнит-тесты и нужны.
·>Я эту багу поймаю на и-тесте repo+dbms — пытаясь воспроизвести пустую колонку.
Вы пытаетесь таблицу истинности запихать куда подальше, в данном случае в бд. А она должна быть прямо рядом с тестом как можно ближе к коду.
Что там будет с бд, когда другой девелопер чего нибудь фиксанет — а хрен его знает.
А если таблица истинности рядом с тестами и тестируемой функцией, шансов намного больше что проблему заметят еще во время код ревью.
P>>Не дополнительными, а теми же самыми интеграционными, что есть и у вас. Интеграционные тесты не пишутся на все вещи вида "проверим что где то внутре передается параметр". Если такое критично — выносится в юниты.
·>Ты не в тему споришь. Ты заявил "Интеграционный тест проверяет 1) что сама склейка валидная". Мест склейки now и nextFriday(now) у тебя будет полно. У меня такое место — одно.
Интеграционный тест проверяет всю интеграцию разом, а вас тянет проверить каждую строчку. Каждая строчка — это про юнит-тестирование.
P>>Если у нас код контролера линейный, а в моем случае это именно так, то нам нужен ровно один интеграционный тест, который нужен и вам
·>_Такой_ интеграционный тест мне не нужен. Я могу обойтись одним ю-тестом с моком о том, что nextFriday() действительно возвращает правильные даты для разных моментов времени. И ещё соответсвующими ю-тестами в местах использования nextFriday(), там можно моком просто возвращать хоть семь пятниц на неделе.
Какой такой? Вам всё равно нужен интеграционный тест. Задачи интеграционных тестов не каждую склейку проверять по отдельности, а проверять работает ли компонент собраный целиком. Что там унутре — для интеграционного тестирования по барабану — нужная функция работает, значит всё хорошо.
P>>Никак.
·>Именно. Т.е. усложняешь прод-код, теряешь возможность протестировать и ловишь баги в проде. Нам такого не надо.
Забавная телепатия.
P>>У вас причин для изменения гораздо больше — любое измение дизайна означает поломку ваших тестов на моках.
·>Это страшилки.
Это следует из ваших примеров.
·>Мде. Если хочешь строчки считать по честному, показывай изменения в прод коде и тест на каждый вызов nextFriday.
Тест на каждый вызов это классика тавтологичного тестирования
P>>ок — на 4.
·>Я тоже так умею:
·>
·>Сейчас начнёшь символы считать, да?
Обычное правило — 1 инструкция на строку. Вы втюхали минимум две. А поскольку у вас значения захардкожены, то между разными тестами согласованность никак не проверяется, т.к. везде хардкодите значения.
P>>Смотрите выше — я вас просил хороший вариант тестирования кода с hmac. Вы во второй раз показали моки, хотя и сами пишете, что так делать не надо.
·>А что там хочешь увидеть, я не понял. Для каждого теста hmac будет известным и фиксированным. Ассертишь по значению, да и всё.
Ну ок.
P>>И не собираюсь — data complexity решается совсем другими инструментами. Количество перестановок в фильтрах спокойно может исчисляться чудовищным количеством кейсов. Если некто поправит запрос, и забудет нагенерерить сотню другую данных — приплыли.
·>Именно. Так что неясно зачем ты делаешь эти предъявы о гарантиях. У тебя аргументация вида "Раз ваш подход не умеет кофе варить и тапочки приносить — значит это плохо и надо делать как фаулер завещал".
Вы забыли, что именно вы претендуете что решите это всё тестами.
P>>т.е. вы снова притягиваете решение которое зависит от человеческого фактора
·>А у тебя есть решение независящее от человеческого фактора?
Его можно ограничить контролируя построение запроса + таблицу истинности храним не абы где, а рядом. Вы же все хотите таблицу истинности или размазать, или запихать куда подальше.
P>>тот самый интеграционный тест, на некорретном запросе он упадет
·>Т.е. у тебя интеграционные тесты будет тестировать всё "чудовищное количество кейсов"? Накой тогда ю-тесты?
Интеграционные тесты не проверяют варианты склейки — они проверяют функционирование в сборе. Юнит-тесты проверяют работоспособность примитивов.
·>Я это знаю из тригонометрии, от моего кода не зависящей. А вот то, что fn2 — правильно, а fn3 — неправильно ты знаешь только из "как в коде написано". Т.е. твой код тестирует самого себя, порочный круг
называется.
Не из кода, а из требований вызывающей стороны.
P>>fn1 и fn2 должны быть видны в тестах, а не публично
·>А тесты должны, по уму, тестировать публичный контракт. @VisibleForTesting — это очень хороший сигнал code smells.
Это ваша фантазия — эдак у вас юнит-тесты станут code smell, тк они принципиально по своей сути видят слишком много.
P>>Тем, что у вас в тестовой бд может не оказаться тех самых значений, которые ломают один из сотен-тысяч кейсов
·>И у вас в тестах может не оказаться тех самых значений для построения того самого ломающего запроса. Опять "тапочки не приносит"?
В моем случае таблица истинности рядом с тестом и функцией. Вы же ее пихаете куда подальше — прямо в бд.
Скажите честно — у вас есть требование по процессу во время код ревью обязательно смотреть содержимое тестовой бд? Те самые десятки-сотни-тысячи записей
P>>Для этого вам надо перебрать все возможные сочетания фильтров -> здесь счет тестов идет на десятки тысяч по скромной оценке
·>Нам — не надо.
Вероятно, это особенность вашего проекта. Любая более-менее внятная статистика-аналитика по бд это довольно сложные алгоритмы, и здесь нужно чтото лучше, чем смотреть в бд и думать, что же должно быть на выходе.
P>>Выборочные тесты. Поскольку я знаю, как строятся фильтры, мне нужно убедиться, что они таки вызываются. И не надо проверять всё перестановки.
·>Ага. Именно то самое whitebox, котором ты ещё недавно меня попрекал.
Раскройте глаза — здесь блекбокс. Выборочно вызываем бд нашим кодом, проверяется весь пайплайн в сборе, косвенно. Только нам не надо проверять всё на свете таким образом, т.к. есть и другие инструменты.
P>>И вы уверены, что в тестовой бд всегда будет полный фарш? Вы что, один работаете?
·>"Тапочки не приносит".
Вы никак не можете объяснить преимущества размазывания таблицы истинности по тестами и бд, чем это лучше хранения таблицы истинности рядом с кодом и функцией с тестом.
P>>Противоречие у вас в голове. Сказано — полного контроля не дают.
·>Именно. Зачем же тогда покрыть юнит-тестами?
—
Затем, что доказательство корректности — это необходимое условие. А такое доказательство + тесты + код ревью, необходимое и достаточное.
P>>·>Как доказывать корректность запроса?
P>>Да как обычно это делается с алгоритмами.
·>И что мешает это же делать в repo+dbms?
Вы же сами говорите,что про это не думаете, верите только в результаты. Вот вы и нашли, кто мешает.
P>>Откуда у вас знание "слишком" или "не слишком" ? Вы даже не в курсе, что за проект, но делаете какие то суждения. Для того проекта — нет, не слишком.
·>Это значит, что изменение в коде занимает как минимум день для выкатки в прод. Значит глобально архитектура выбрана плохо. Возможно надо резать на независимые компоненты.
Нет, не значит.
Вы не в курсе, ни что за проект, ни какие требования, итд. Далеко не все проекты могут протаскивать изменения в прод прям сразу.
Во вторых, я вам сказал, что это полная сборка, все платформы, всё-всё-всё. Кто вам сказал, что нет сборки отдельных модулей?
И так у вас всё — вместо вопросов занимаетесь телепатией.
P>>Переписывать то зачем? Чем они вам мешают?
·>Тем, что они написаны на конкретном ЯП.
Я ж сказал — если по аннотации можно сгенерировать 4 артефакта, то почему нельзя сгенерировать 5й, 6й, 7й?
Вы же видите только переписывание
P>>·>Смотря как долго проект живёт.
P>>Чем дольше, тем меньше шансов на переписывание, проще заново напилить новое.
·>Но при сохранении контракта, который у вас описан на аннотациях конкретного ЯП. В общем гугли ликбез, например, тут https://swagger.io/blog/code-first-vs-design-first-api/
Вы путаете code-first и design-first. design first — означает, что первое деливери это апи, а не реализация. code-first — наоборот. А какой файл вы в начале редактируете, json или java и yaml, дело десяток
Я ж сразу сказал — апи уже есть, а реализации нету, зато можно и тесты писать, и клиентский код, и документацию прикручивать
>>> Твои "{...toFields}" — тоже лишний код, и это всё прод-код.". Ты только от первого открестился, а на вторые два сделал вид, что их не было.
P>>{...toFields} экономит вам десяток другой методов и тестов для них. Если у вас нет такого метода, вам придется или по месту колбасить код, намного больше, или создавать все возможные методы для конверсии.
·>Не экономит. Конкретные типы и конструкторы с ними соответствуют конкретным арифметическим операциям с календарём. Твоё toFields — какое-то месиво, неясно о чём и чревато багами. Скажем, если у тебя тип time окажется какого-то не того типа, то эта твоя ... начнёт давать странное месиво с неясным результатом из=за перекрытия одноимённых полей. Не надо так делать.
Ваша альтернатива — понасоздавать вагон методов для конверсии "всё во всё" что дает вагон кода и вагон тестов. Или же вместо однострочной конверсии у вас будет несколько строчек кода точно так же без полного контроля.
P>>Потому, что одного теста на моках, как вы показываете, недостаточно. Вам придется вместо таблицы инстинности приседать с моками.
·>Недостаточно для чего? Почему недостаточно? Причём тут таблица истинности?
Логику, вычисления мы тестируем по таблице истинности. И чем меньше дополнительного кода сверх этой таблицы истинности, тем лучше. А вам надо все поразмазывать по мокам
P>>Вы уже показали — кода в тестах в вашем исполнении больше.
·>Больше, т.к. код делает больше.
Функционально — ровно столько же.
P>>У вас какая то мешанина — интерграционные это все что выше юнитов. Сценарии — это на самом верху, уровень приложения или всей системы. Не ясно, за счет чего у вас будет меньше интеграционных — похоже, вы верите, что моки здесь чего то решают.
·>Меньше интеграционных за счёт того, что они тестируют интеграцию. А не всю копипасту, которую ты предлагаешь плодить.
Моки не тестируют интеграцию. Моком вы можете проверить, а что будет, если подкинуть ту или иную зависимость. А нам надо совсем другое — готовый компонент работает как нам надо.
Это разные вещи и вы продолжаете путать.
Количество интеграционных тестов моки уменьшить никак не могут. Моки — это фактически понижение уровня тестирования за счет обрезания зависимостей. Нам же надо не понижение, а повышение.
P>>Это ж не значит, что и применять данных подход нужно везде. В некоторых интеграционных тестах, которых обычно немного.
·>Как немного? Ты пишешь по интеграционному тесту для каждого do_logic. Т.к. именно там происходит склейка.
Есть метод — его нужно вызвать в тестах. И у вас будет ровно то же. Просто вас тянет тестировать код, а не ожидания вызывающей стороны.
Склейка или нет дело десятое — вызывающая сторона никаких ожиданий на этот счет не имеет, ей про это неизвестно.
Проверка конкретной склейки — это вайтбокс, тест "как написано", классика тавтологии.
Вместо проверки конкретной склейки делаем интеграционный код линейным, буквально, а интеграцию осуществляем на самом верху.
P>>deep equals проверяет значение, всё разом, если у вас чтото больше чем инт или строка
·>Я знаю. И это плохо, особенно для юнит-тестов.
Простите, вы мапперы из одной структуры в другую как тестировать собираетесь? А парсинг? А как вы проверите, что ваш репозиторий на конкретный запрос вернет ту самую структуру? Например, нам нужен order + order items + customer + delivery + billing
Как вы собираетесь протестировать результат?
P>>Поломаются тесты не там, где вы обмокали, а ровно по месту — меняется таблица истинности функции
·>Так функция может использоваться из множества мест.
Пусть используется. Что вас смущает ?
P>>В вашем случае далеко не факт, что найдете в моках все нужные места, и сделаете что бы соответствовало
·>Какие места? Зачем их искать?
Читайте себя "Так функция может использоваться из множества мест."
У вас в тех самых тестах все будет обмокано. Как узнаете, что там, в моках, должно вызываться не "то", а "это"?
P>>Если у вас будет подсчет статистики, вы вспотеете покрывать тестами "из базы"
·>Ты потерял контекст. Тут шла речь о ю-тест упоминал "а что если в колонке пусто". В колонке, внезапно окажется, будет не пусто а дефолтное значение из бд. Багу такую поймаешь только на проде, т.к. и-тесты для таких подробных мелочей явно писать не будешь.
Наоборот — именно для таких мелочей юнит-тесты и нужны.
·>Я эту багу поймаю на и-тесте repo+dbms — пытаясь воспроизвести пустую колонку.
Вы пытаетесь таблицу истинности запихать куда подальше, в данном случае в бд. А она должна быть прямо рядом с тестом как можно ближе к коду.
Что там будет с бд, когда другой девелопер чего нибудь фиксанет — а хрен его знает.
А если таблица истинности рядом с тестами и тестируемой функцией, шансов намного больше что проблему заметят еще во время код ревью.
P>>Не дополнительными, а теми же самыми интеграционными, что есть и у вас. Интеграционные тесты не пишутся на все вещи вида "проверим что где то внутре передается параметр". Если такое критично — выносится в юниты.
·>Ты не в тему споришь. Ты заявил "Интеграционный тест проверяет 1) что сама склейка валидная". Мест склейки now и nextFriday(now) у тебя будет полно. У меня такое место — одно.
Интеграционный тест проверяет всю интеграцию разом, а вас тянет проверить каждую строчку. Каждая строчка — это про юнит-тестирование.
P>>Если у нас код контролера линейный, а в моем случае это именно так, то нам нужен ровно один интеграционный тест, который нужен и вам
·>_Такой_ интеграционный тест мне не нужен. Я могу обойтись одним ю-тестом с моком о том, что nextFriday() действительно возвращает правильные даты для разных моментов времени. И ещё соответсвующими ю-тестами в местах использования nextFriday(), там можно моком просто возвращать хоть семь пятниц на неделе.
Какой такой? Вам всё равно нужен интеграционный тест. Задачи интеграционных тестов не каждую склейку проверять по отдельности, а проверять работает ли компонент собраный целиком. Что там унутре — для интеграционного тестирования по барабану — нужная функция работает, значит всё хорошо.
P>>Никак.
·>Именно. Т.е. усложняешь прод-код, теряешь возможность протестировать и ловишь баги в проде. Нам такого не надо.
Забавная телепатия.
P>>У вас причин для изменения гораздо больше — любое измение дизайна означает поломку ваших тестов на моках.
·>Это страшилки.
Это следует из ваших примеров.
·>Мде. Если хочешь строчки считать по честному, показывай изменения в прод коде и тест на каждый вызов nextFriday.
Тест на каждый вызов это классика тавтологичного тестирования
P>>ок — на 4.
·>Я тоже так умею:
·>
·>var clock = mock(InstantSource.class);
·>var testSubject = new CalendarLogic(clock);
·>when(clock.instant()).thenReturn(Instant.of("2023-12-28T12:27:00Z"));assertThat(testSubject.nextFriday()).equalTo(LocalDate.of("2023-12-29"));
·>when(clock.instant()).thenReturn(Instant.of("2023-12-29T23:59:59Z"));assertThat(testSubject.nextFriday()).equalTo(LocalDate.of("2023-12-29"));
·>when(clock.instant()).thenReturn(Instant.of("2023-12-30T00:00:00Z"));assertThat(testSubject.nextFriday()).equalTo(LocalDate.of("2024-01-05"));
·>·>Сейчас начнёшь символы считать, да?
Обычное правило — 1 инструкция на строку. Вы втюхали минимум две. А поскольку у вас значения захардкожены, то между разными тестами согласованность никак не проверяется, т.к. везде хардкодите значения.
P>>Смотрите выше — я вас просил хороший вариант тестирования кода с hmac. Вы во второй раз показали моки, хотя и сами пишете, что так делать не надо.
·>А что там хочешь увидеть, я не понял. Для каждого теста hmac будет известным и фиксированным. Ассертишь по значению, да и всё.
Ну ок.
P>>И не собираюсь — data complexity решается совсем другими инструментами. Количество перестановок в фильтрах спокойно может исчисляться чудовищным количеством кейсов. Если некто поправит запрос, и забудет нагенерерить сотню другую данных — приплыли.
·>Именно. Так что неясно зачем ты делаешь эти предъявы о гарантиях. У тебя аргументация вида "Раз ваш подход не умеет кофе варить и тапочки приносить — значит это плохо и надо делать как фаулер завещал".
Вы забыли, что именно вы претендуете что решите это всё тестами.
P>>т.е. вы снова притягиваете решение которое зависит от человеческого фактора
·>А у тебя есть решение независящее от человеческого фактора?
Его можно ограничить контролируя построение запроса + таблицу истинности храним не абы где, а рядом. Вы же все хотите таблицу истинности или размазать, или запихать куда подальше.
P>>тот самый интеграционный тест, на некорретном запросе он упадет
·>Т.е. у тебя интеграционные тесты будет тестировать всё "чудовищное количество кейсов"? Накой тогда ю-тесты?
Интеграционные тесты не проверяют варианты склейки — они проверяют функционирование в сборе. Юнит-тесты проверяют работоспособность примитивов.
·>Я это знаю из тригонометрии, от моего кода не зависящей. А вот то, что fn2 — правильно, а fn3 — неправильно ты знаешь только из "как в коде написано". Т.е. твой код тестирует самого себя, порочный круг
называется.
Не из кода, а из требований вызывающей стороны.
P>>fn1 и fn2 должны быть видны в тестах, а не публично
·>А тесты должны, по уму, тестировать публичный контракт. @VisibleForTesting — это очень хороший сигнал code smells.
Это ваша фантазия — эдак у вас юнит-тесты станут code smell, тк они принципиально по своей сути видят слишком много.
P>>Тем, что у вас в тестовой бд может не оказаться тех самых значений, которые ломают один из сотен-тысяч кейсов
·>И у вас в тестах может не оказаться тех самых значений для построения того самого ломающего запроса. Опять "тапочки не приносит"?
В моем случае таблица истинности рядом с тестом и функцией. Вы же ее пихаете куда подальше — прямо в бд.
Скажите честно — у вас есть требование по процессу во время код ревью обязательно смотреть содержимое тестовой бд? Те самые десятки-сотни-тысячи записей
P>>Для этого вам надо перебрать все возможные сочетания фильтров -> здесь счет тестов идет на десятки тысяч по скромной оценке
·>Нам — не надо.
Вероятно, это особенность вашего проекта. Любая более-менее внятная статистика-аналитика по бд это довольно сложные алгоритмы, и здесь нужно чтото лучше, чем смотреть в бд и думать, что же должно быть на выходе.
P>>Выборочные тесты. Поскольку я знаю, как строятся фильтры, мне нужно убедиться, что они таки вызываются. И не надо проверять всё перестановки.
·>Ага. Именно то самое whitebox, котором ты ещё недавно меня попрекал.
Раскройте глаза — здесь блекбокс. Выборочно вызываем бд нашим кодом, проверяется весь пайплайн в сборе, косвенно. Только нам не надо проверять всё на свете таким образом, т.к. есть и другие инструменты.
P>>И вы уверены, что в тестовой бд всегда будет полный фарш? Вы что, один работаете?
·>"Тапочки не приносит".
Вы никак не можете объяснить преимущества размазывания таблицы истинности по тестами и бд, чем это лучше хранения таблицы истинности рядом с кодом и функцией с тестом.
P>>Противоречие у вас в голове. Сказано — полного контроля не дают.
·>Именно. Зачем же тогда покрыть юнит-тестами?
—
Затем, что доказательство корректности — это необходимое условие. А такое доказательство + тесты + код ревью, необходимое и достаточное.
P>>·>Как доказывать корректность запроса?
P>>Да как обычно это делается с алгоритмами.
·>И что мешает это же делать в repo+dbms?
Вы же сами говорите,что про это не думаете, верите только в результаты. Вот вы и нашли, кто мешает.
P>>Откуда у вас знание "слишком" или "не слишком" ? Вы даже не в курсе, что за проект, но делаете какие то суждения. Для того проекта — нет, не слишком.
·>Это значит, что изменение в коде занимает как минимум день для выкатки в прод. Значит глобально архитектура выбрана плохо. Возможно надо резать на независимые компоненты.
Нет, не значит.
Вы не в курсе, ни что за проект, ни какие требования, итд. Далеко не все проекты могут протаскивать изменения в прод прям сразу.
Во вторых, я вам сказал, что это полная сборка, все платформы, всё-всё-всё. Кто вам сказал, что нет сборки отдельных модулей?
И так у вас всё — вместо вопросов занимаетесь телепатией.
P>>Переписывать то зачем? Чем они вам мешают?
·>Тем, что они написаны на конкретном ЯП.
Я ж сказал — если по аннотации можно сгенерировать 4 артефакта, то почему нельзя сгенерировать 5й, 6й, 7й?
Вы же видите только переписывание
P>>·>Смотря как долго проект живёт.
P>>Чем дольше, тем меньше шансов на переписывание, проще заново напилить новое.
·>Но при сохранении контракта, который у вас описан на аннотациях конкретного ЯП. В общем гугли ликбез, например, тут https://swagger.io/blog/code-first-vs-design-first-api/
Вы путаете code-first и design-first. design first — означает, что первое деливери это апи, а не реализация. code-first — наоборот. А какой файл вы в начале редактируете, json или java и yaml, дело десяток
Я ж сразу сказал — апи уже есть, а реализации нету, зато можно и тесты писать, и клиентский код, и документацию прикручивать