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

g> ·>Это значит, что тебе повезло и тебе надо тестировать мало сценариев. Какой-то небольшой проект, значит.
g> Если одно изменение меняет все респонзы всех эндпоинтов сервиса — это вопрос к дизайну контрактов, а не к размеру проекта.
Да тупо — новое поле добавить — всё, полное сравнение падает. Поменяли формат id-шника — всё не совпадает.

g> ·>Это опять же не масштабируется на большие проекты. Небольшое изменение будет ломает несколько мест нескольких крупных тестов и становится очень неочевидно что именно и почему сломалось и что где чинить.
g> Не вижу тут связи с размером проекта. Сервис может иметь сотни эндпоинтов (хотя такой микросервис уже кандидат на разделение), но дизайн контракта спроектирован так, что изменения в DTO максимально изолированы.
Зависит от сложности dto ещё. Вон в FX Options, сотня полей. всякие greeks в разных валютах, в разных моделях или типа того... И все эти json-портянки ломаются внезапно при маленьком изменении.

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

S>>·>Автотестом. Я в одном из предыдущих сообщений показал примерный код. Вставить документы через dao, выбрать и проверить, что выбралось только то что надо. Какие при этом гуляют тексты sql — вообще по барабану.
S>>Интересно, а как вы будете проверять запрос "вернуть 2 страницу из 100 документов по вот таким критериям"?
·>А что уж не из миллиарда? Кол-во документов на странице — это параметр. Вот и достаточно протестировать, из 4 документов 3 фильтруются и третий выводится на 2й странице, при заданном размере страницы в 2 документа.

Я такое видел, кстати. Что бы проверить постраничную выдачу, сделали размер страницы 2. И до сих пор вылазят баги, если юзер выставляет другой размер страницы А тесты зеленые, кстати.

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

S>>>Интересно, а как вы будете проверять запрос "вернуть 2 страницу из 100 документов по вот таким критериям"?
P>·>А что уж не из миллиарда? Кол-во документов на странице — это параметр. Вот и достаточно протестировать, из 4 документов 3 фильтруются и третий выводится на 2й странице, при заданном размере страницы в 2 документа.
P>Я такое видел, кстати. Что бы проверить постраничную выдачу, сделали размер страницы 2.
А ещё они огурцы ели.

P>И до сих пор вылазят баги, если юзер выставляет другой размер страницы А тесты зеленые, кстати.
А добавить ещё тест им запретили?

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

g>> ·>Это опять же не масштабируется на большие проекты. Небольшое изменение будет ломает несколько мест нескольких крупных тестов и становится очень неочевидно что именно и почему сломалось и что где чинить.
g>> Не вижу тут связи с размером проекта. Сервис может иметь сотни эндпоинтов (хотя такой микросервис уже кандидат на разделение), но дизайн контракта спроектирован так, что изменения в DTO максимально изолированы.
·>Зависит от сложности dto ещё. Вон в FX Options, сотня полей. всякие greeks в разных валютах, в разных моделях или типа того... И все эти json-портянки ломаются внезапно при маленьком изменении.

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

Здравствуйте, gyraboo, Вы писали:
g> ·>Зависит от сложности dto ещё. Вон в FX Options, сотня полей. всякие greeks в разных валютах, в разных моделях или типа того... И все эти json-портянки ломаются внезапно при маленьком изменении.
g> Так они и должны меняться, это же контракт.
Я не против. Проблема в том, что тесты должны быть максимально локальными. В том смысле, что если я "ломаю" что-то одно, это в идеале должно сломать ровно один тест.
Ситуация, когда одно изменение ломает все тесты — плохая.

g> Если в крупной json меняется пара полей, то интегротест же выдаёт diff конкретно для сломанного поля, что позволяет быстро определить точку поломки.
Да. Но так как этих json сотни, то тебе тупо выдаст сотни диффов с одним и тем же полем, и нужно пройтись по всем этим json-ам и добавить туда одно и то же. Совершенно бесполезно и даже вредно, типичный копипаст.

g> Поэтому не очень понимаю, в чём проблема использования больших json, цельных с точки зрения реквест-респонзов.
В том, что желательно иметь минимальные изменения. Одно поле добавлено — один тест поправлен. (повторюсь, это идеал, но хочется к нему стремиться)

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

g>> Если в крупной json меняется пара полей, то интегротест же выдаёт diff конкретно для сломанного поля, что позволяет быстро определить точку поломки.
·>Да. Но так как этих json сотни, то тебе тупо выдаст сотни диффов с одним и тем же полем, и нужно пройтись по всем этим json-ам и добавить туда одно и то же. Совершенно бесполезно и даже вредно, типичный копипаст.

В описываемом мною подходе нет сотни диффов, потому что интегротесты не тестируют все краевые условия и классы эквивалентности, иначе прогон интегротестов займет сутки, это слишком "дорого", для этого существуют "дешевые" юнит-тесты, которые гоняются на порядок быстрее и могут пройтись по всем значимым входным и выходным значениям. Интегротесты тестируют в основном критический путь, и то дишь в том объеме, чтобы проверить исполнение контракта для любого из значений, а не для всех классов эквивалентности. Поэтому интегротестов на практике получается не так много.

g>> Поэтому не очень понимаю, в чём проблема использования больших json, цельных с точки зрения реквест-респонзов.
·>В том, что желательно иметь минимальные изменения. Одно поле добавлено — один тест поправлен. (повторюсь, это идеал, но хочется к нему стремиться)

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

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


g> В описываемом мною подходе нет сотни диффов, потому что интегротесты не тестируют все краевые условия и классы эквивалентности, иначе прогон интегротестов займет сутки, это слишком "дорого", для этого существуют "дешевые" юнит-тесты, которые гоняются на порядок быстрее и могут пройтись по всем значимым входным и выходным значениям. Интегротесты тестируют в основном критический путь, и то дишь в том объеме, чтобы проверить исполнение контракта для любого из значений, а не для всех классов эквивалентности. Поэтому интегротестов на практике получается не так много.
Так согласен. Изначально ты написал "мокание — это зло. Я последние пару лет пришёл к такому способу: интегротесты". А если моканье зло, то и юнит-тесты зло, ибо без моканья они не работают. Вот я и не понял, что ты имеешь в виду. Да, итесты тоже нужны, но мало, по нескольким основным сценариям. А подавляющее большинство — это ютесты на моках.

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

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


·>Так согласен. Изначально ты написал "мокание — это зло. Я последние пару лет пришёл к такому способу: интегротесты". А если моканье зло, то и юнит-тесты зло, ибо без моканья они не работают. Вот я и не понял, что ты имеешь в виду. Да, итесты тоже нужны, но мало, по нескольким основным сценариям. А подавляющее большинство — это ютесты на моках.

Юнит-тесты без моков возможны. Нужно выносить сложную логику в чистые функции.
Оставшуюся часть покрывать интеграционными тестами (самым длинным happy-path)

Сложный алгоритм, мало взаимодействия => юнит-тесты
Простой алгоритм, много взаимодействия => интеграционный тест
Сложный алгоритм, много взаимодействия => рефакторить
Простой алгоритм, мало взаимодействия => не тестировать

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

Б> ·>Так согласен. Изначально ты написал "мокание — это зло. Я последние пару лет пришёл к такому способу: интегротесты". А если моканье зло, то и юнит-тесты зло, ибо без моканья они не работают. Вот я и не понял, что ты имеешь в виду. Да, итесты тоже нужны, но мало, по нескольким основным сценариям. А подавляющее большинство — это ютесты на моках.
Б> Юнит-тесты без моков возможны. Нужно выносить сложную логику в чистые функции.
Это скучный случай. Если появляется состояние, то никаких чистых функций не остаётся. Какая-нибудь state machine тестируется, к которой разные события от многих источников приходят в разном порядке и ожидаются соответствующие действия.

Б> Оставшуюся часть покрывать интеграционными тестами (самым длинным happy-path)
А что делать, например, с кодом взаимодействия с бд? Что запросы нужные шлются, что результаты правильные приходят?

Б> Сложный алгоритм, много взаимодействия => рефакторить
Тут можно только на компоненты разбить рефакторингом. Чтобы простые компоненты делали простые действия. Это, однако, требует системных тестов — когда все эти компоненты собираются в единую систему и проверяется что это всё вместе сразу хоть как-то работает.

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

S>>Ну, вам виднее. Если вы не хотите иметь возможности запускать тесты параллельно и обходиться без подключения к базе — то велком.
·>Тесты базы запускать без базы — бессмысленно.

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

S>>И ваш тест нельзя исполнять параллельно с другими тестами — мало ли кто там ещё какие документы сохраняет.
·>В случае in-memory — элементарно. Впрочем бывают и другие способы изоляции, зависит от предметной области.

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

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

S>В обоих случаях мы можем убедиться, что запрос построен корректно, без вызова удалённого сервиса, и без порождения HTTP запросов.

Это хорошо, если клиент позволяет такое. А вот, например, у нас есть простецкий сервис — у него работа с медленным стораджем + кеширование в редисе.

Мне вот трудно понять, как нам внятно покрыть тестами и работу с редисом.
Что предложишь в этом случае?

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

S>>>Ну, вам виднее. Если вы не хотите иметь возможности запускать тесты параллельно и обходиться без подключения к базе — то велком.
P>·>Тесты базы запускать без базы — бессмысленно.
P>Ты предлагаешь вообще использова ин-мемори базу. То есть, вполне себе есть шанс, что на каких то интересных условиях, или сложных кейсах, мы и словим разницу между бд, скорее всего на проде.
Тебе я предлагаю читать внимательнее. Моя цитата:

Я же говорю, ровно эти же тесты гоняются потом с настоящей dbms по ночам в CI. А in-memory для быстрого девелопинга локально.

S>>>И ваш тест нельзя исполнять параллельно с другими тестами — мало ли кто там ещё какие документы сохраняет.
P>·>В случае in-memory — элементарно. Впрочем бывают и другие способы изоляции, зависит от предметной области.
P>на мой взгляд импользоват ин-мемори в тестах можно для функциональных тестов. А вот для тестов, где будут покрываться самые разные варианты обращений к бд ин-мемори это обманка, т.к. точно работает не так, как база на проде.
P>А нам надо убедиться, что наш функционал корректно будет слать ожидаемые запросы именно на проде.
Зависит от размера и содержимого прода. Например, в одной ситуации субд у нас была вменяемого размера, но с sensitive-данными, которые было запрещено даже читать за пределами прода. Поэтому был cleansing-процесс который делал модифицированную копию данных с затёртой рандомом sensitive информацией. На этой копии и гонялись тесты.

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

S>>>>И ваш тест нельзя исполнять параллельно с другими тестами — мало ли кто там ещё какие документы сохраняет.
P>>·>В случае in-memory — элементарно. Впрочем бывают и другие способы изоляции, зависит от предметной области.
P>>на мой взгляд импользоват ин-мемори в тестах можно для функциональных тестов. А вот для тестов, где будут покрываться самые разные варианты обращений к бд ин-мемори это обманка, т.к. точно работает не так, как база на проде.
P>>А нам надо убедиться, что наш функционал корректно будет слать ожидаемые запросы именно на проде.
·>Зависит от размера и содержимого прода. Например, в одной ситуации субд у нас была вменяемого размера, но с sensitive-данными, которые было запрещено даже читать за пределами прода. Поэтому был cleansing-процесс который делал модифицированную копию данных с затёртой рандомом sensitive информацией. На этой копии и гонялись тесты.

Я тебе про базы, а ты мне размер. У тебя должна быть БД с точно таким же движком, такой же версии, только ин-мемори.
Если движок не тот — а хрен его знать, что на проде
Если не ин-мемори, то количество тестов будет плачевным в силу времени их выполнения

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

P>·>Зависит от размера и содержимого прода. Например, в одной ситуации субд у нас была вменяемого размера, но с sensitive-данными, которые было запрещено даже читать за пределами прода. Поэтому был cleansing-процесс который делал модифицированную копию данных с затёртой рандомом sensitive информацией. На этой копии и гонялись тесты.
P>Я тебе про базы, а ты мне размер. У тебя должна быть БД с точно таким же движком, такой же версии, только ин-мемори.
Ты цитату выше нарочно обрезал что-ли, дабы во второй раз чушь спороть? Мне не лень повторить: "гоняются потом с настоящей dbms". И, ясен пень, версия берётся ровно та же, что и на проде, неясно вообще зачем брать другую. Нынче с докерами это делается вообще элементарно.
Проблема именно с данными. Если бд огромного размера, то иметь копию чисто тесты погонять — становится непозволительной роскошью.

P>Если движок не тот — а хрен его знать, что на проде
P>Если не ин-мемори, то количество тестов будет плачевным в силу времени их выполнения
С двухнедельными спринтами можно позволить себе тесты гонять хоть неделю, CI железный, ему пофиг.

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

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

vsb>Задача мне кажется типовой и достаточно универсальной. Но не очень понимаю, как гуглить.

Ничего ты не нагуглишь, если ищешь что-то халявное. Эту систему нужно разрабатывать, у всех система интеграционных тестов своя.

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

P>Мне вот трудно понять, как нам внятно покрыть тестами и работу с редисом.
P>Что предложишь в этом случае?

Надо смотреть в код сервиса — как там сделано кэширование: явно или прозрачно?
Если прозрачно — то там, по большому счёту, тестировать особо нечего, кроме корректности сопоставления ключей для медленного стораджа с ключами для редиса.

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

P>>Мне вот трудно понять, как нам внятно покрыть тестами и работу с редисом.
P>>Что предложишь в этом случае?

S>Надо смотреть в код сервиса — как там сделано кэширование: явно или прозрачно?
S>Если прозрачно — то там, по большому счёту, тестировать особо нечего, кроме корректности сопоставления ключей для медленного стораджа с ключами для редиса.

А если явно, то как?

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

P>>Если движок не тот — а хрен его знать, что на проде
P>>Если не ин-мемори, то количество тестов будет плачевным в силу времени их выполнения
·>С двухнедельными спринтами можно позволить себе тесты гонять хоть неделю, CI железный, ему пофиг.

А вот девелоперам не пофиг. Они не будут ждать неделю, пока у них тесты выполнятся. Есть вполне проверяемая связь — чем дольше выполняются тесты, тем меньше их пишут девелоперы.

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

P>>>Если движок не тот — а хрен его знать, что на проде
P>>>Если не ин-мемори, то количество тестов будет плачевным в силу времени их выполнения
P>·>С двухнедельными спринтами можно позволить себе тесты гонять хоть неделю, CI железный, ему пофиг.
P>А вот девелоперам не пофиг. Они не будут ждать неделю, пока у них тесты выполнятся. Есть вполне проверяемая связь — чем дольше выполняются тесты, тем меньше их пишут девелоперы.
Полные тесты гоняются на rc-версии. Девелоперы этим не заморачиваются, они строгают в master.

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

P>>·>С двухнедельными спринтами можно позволить себе тесты гонять хоть неделю, CI железный, ему пофиг.
P>>А вот девелоперам не пофиг. Они не будут ждать неделю, пока у них тесты выполнятся. Есть вполне проверяемая связь — чем дольше выполняются тесты, тем меньше их пишут девелоперы.
·>Полные тесты гоняются на rc-версии. Девелоперы этим не заморачиваются, они строгают в master.

Звучит так, будто девелоперам пофигу, сколько ждать результатов — час, день или месяц.
И что значит полные или неполные?
Ты собираешься все юнит-тесты сделать медленными, ну вот у Postgress насколько я знаю, нет inmemory версии, если я не ошибаюсь.
Значит будет медленно. Твой подход — тестировать большую длинную цепочку в одном тесте:
— бл, подготовил параметры
— подготовил запрос
— отправил, получил ответ
— обработал ответ
— бл, подготовил результат
Такая цепочка будет дополнительно замедлять
1. нельзя выполнять параллельно, например, потому, что запросы могут модифицировать чего
2. в каждой операции может быть кучка взаимодействия и так с медленной бд

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