как выше уже заметили, вам просто нужно отделить кафку от бизнес логики, и тогда вы обойдетесь тривиальными настройками. Более того, эта настройка становится единообразной для любых зависимостей, будь то рест, БД, кафка или что-то еще.
Обычно предлог для использования тестового контейнера или иного сложного мока состоит в том, что он содержит какую-то логику, которую хотелось бы сохранить и поменять которую нет возможности. Ну, типа, послал сообщение - в ответ приехало сообщение и т.п. Но даже в этом случае легче написать простой фейковый кафка провайдер, который будет отражать логику, которую вы ожидаете от реальной зависимости.
Спасибо большое за статью, очень здорово видеть ТДД, и кажется очевидным, что это делает код чище.
В имплементации же многое можно улучшить. Разница между given и when в том, что одно предусловие, а второе условие, и если предусловия мы принимает как есть, то в условии мы проверяем все кейсы, в этом сила конвенции.
Ну, скажем, вот у вас куча отдельных given'ов и одинаковые when'ы. Тут должно быть что-то вроде
givenModuleAndFactoryAndTempDir - потому что вы полагаетесь на их существование,
whenDependencyExcluded - а тут мы проверяем все случаи
Или вот еще пример
Тут тоже явно перебираются условия в given.
Ну и когда я вижу условия, я автоматически начинаю искать пропущенные - где все корнер-кейсы-то, т.е. пустые и несуществующие папки, пустые или некомпилируемые файлы, частично компилируемые файлы и т.п.?
Если же вы все это уже проверили в других местах, значит это предусловие и должно быть обозначено в given.
Сила ТДД в том, что можно посмотреть на тесты и понять, как должен вести себя код и что пропущено, - но из этих тестов этого пока не понятно.
(Слова типа Is, Are можно опускать в заголовках и тестах, они не нужны).
Ну, юнит-тесты нужны не для тестирования алгоритмов сортировки, а для тестирования дыр в системе типов. Нуль-пойнтеры, непустые коллекции, валидация полей, off-by-one, business exceptions, cross-field validations - пример вашего кода не проверяет из этого ничего, кроме того, что вы таки передали параметры в send. Иначе юнит тестов стало бы в 5-10 раз больше - как юнит-тестам и положено.
Метод convertContentToEntityDescriptor можно вызвать отдельно и передать его результат в основной метод, тогда и Mockito не понадобится.
Заменять юнит-тесты на RnR нет никакой необходимости - мы не можем записывать отдельную кассету для каждого нуль-пойнтера.
У RnR безусловно есть ниша, но она не совсем там, где вы описываете. Я вижу два, как минимум кейса.
1) - легаси API. Например, в вашем случае если нам надо послать все через CrappyGenericLegacyService, который два бизнес-поля превращает в сто полей, содержит private static void methods, половину ошибок глотает, а половину выплевывает во внешний сервис, который содержит в качестве зависимости. Проверять все ассертами долго, юнит тестами не подлезть. Да мы часто и не знаем, что именно проверять, а знать, что из него послано - хотелось бы. В этом случае RnR подходит идеально - легаси меняется редко и его поведение, как правило, детерминировано.
2) - матмодели. Если на вход подается два датасета и десять параметров, а на выходе еще один датасет значений в 1000 - сетапить тяжело, и отдельными ассертами неудобно тестировать.
И в том, и в другом случае RnR не столько тестирует (у него нет given-when-then), сколько подтверждает поведение системы, поэтому достаточно happy path записать.
Ну и в имплементации тоже.
"банальная регулярка" для отсеивания недетерминированных фрагментов - сама по себе источник багов. Практичнее, хотя и дольше, действительно ручками вытащить и записать нужные фрагменты, и иметь полностью детерминированную чистую кассету.
вместо человеко-читаемости кассету гораздо удобнее читать машиной. Для длинной кассеты assertEquals неинформативен. Кассета должна быть diffable и automatable, и дифф просто возвращает номер первой неверной строки.
Важный аргумент в пользу конструкторов - возможность полностью убрать аннотации из бинов и вынести их в отдельные конфиг файлы. Тогда эти классы можно тестировать junit'ом независимо от спринга, держать отдельный конфиг для тестов и отдельный для приложения, или использовать в библиотеке отдельно
Это потому что вы слышали про redux). А я встречал, например, «зачем нам вообще эти мутации, ужасный бойлерплейт, давайте их все завернем в одну общую».
если не спешить и думать головой наперед, можно и на c++ хорошо написать:) вопрос в том, во что превращается проект, когда на нем спешат и не успевают думать.
Вы совершенно правы, и глядя на большие vue проекты уже сейчас, у меня сложилось ясное понимание, что там хелл из всего, что уже намешано. Т.е. логика стихийно попадает в любое из мест: вычисляемые свойства, вотчеры, ивенты, экшены, мутации — и тут мы добавляем еще несколько опций. А поскольку фронтенд — это еще и традиционное место для джуниоров, то их регулировать особенно трудно.
отчего же ярлык?:) Я, кажется, конкретно объяснил почему вью сложнее использовать. Слишком много фич. Фичи не сочетаются друг с другом.
Сравните, например, как выкатываются и обкатываются фичи на реакте.
Китайский в данном случае подход — скопировать идею без понимания и чтоб как будто просто. Там не один разработчик, а целое коммьюнити такое.
>> Кроме того, простота входа привлекает не самых лучших разработчиков — ага, ну давайте сделаем все через одно место, чтобы максимально усложнить всем работу.
нет, давайте установим правила, а не будем давать джуниорам гранаты
это безусловно так, китайская библиотека, копирующая фичи и упрощающая синтаксис. Vue на больших проектах очень трудно использовать уже сейчас (я работал недавно на проекте в 60+ человек), потому что кто-то пишет коммуникацию через VueX, а кто-то через ивенты, и никогда не знаешь, что еще придет в голову и логика расползается повсюду. Тестить это практически невозможно. Кроме того, простота входа привлекает не самых лучших разработчиков. С реактом еще въехать надо, что можно и что нельзя, а тут вперед и с шашкой.
Проблема в том, что это изолированно тестировать почти невозможно. (И вообще с хуками геморрой). При этом обычный React+Redux раскладывался на ComponentTest,ActionTest,ReducerTest прямиком, тем и был силен.
если команда отвечает за сервис от начала до конца, это не значит, что нужно пренебрегать практиками. Cloud-native, 12-factor и тп
Интеграционные тесты приложения вместе с окружающей средой вредят и приложению, и окружающей среде. Индустрия в принципе движется туда, где эти вещи ортогональны.
Я в интеграционных тестах концентрируюсь на:
— happy path
— очень ограниченное количество fail case
Дальше из эксплуатации станет понятно, какие кейсы в интеграционные тесты добавить.
Это знакомо, так девяносто процентов делает, т. е. фактически юзеры тестируют.
Тесты валидации, и вообще поведение выставленного API — проверяется в функциональных тестах. Но без деталей. Например для тестов валидации — проверяется что на конкретный запрос в результате инстацируется фабрикой конкретный валидатор и ему передается на валидацию конкретный объект. А все детали валидации тестируются в модульных тестах.
Это тоже знакомый подход — мы решили что будем экономить на тестах и поэтому тестировать только места со сложной логикой. Проблема этого подхода в том, что он inplementation driven. Сложный валидатор может быть следствием плохой разбивки на эндпойнты например. В этих случаях тестируемые места превращаются в логические чёрные дыры, насасывая все больше условий, а остальные части становятся номинальными.
Например, если валидаторы пишет одна команда. А использует их в конкретном сервисе, которые выставляет API, другая команда. Понятно, у первых могут быть свои тесты. Но вторым, чтобы быть уверенными в том, что все работает ожидаемым образом, могут быть свои тесты, реализованные на функциональном-интеграционном слое, которые могут повторять значительную часть логики тестов первой команды.
Если валидаторы пишет другая команда, то это означает, что у нас внешняя зависимость. Для тестирования внешней зависимости мы делаем интеграционный тест для зависимости, который берет внешний урл, это нормально и это единственный валидный кейс для интеграции. Но запускать систему целиком для этого необходимости нет.
Насчёт урла я не понимаю. Урл — это внешний параметр, тестировать его бесполезно. Работающий дев урл ничего не говорит о QA или продакшене.
Про докер я не знаю, что вы конкретно имеете ввиду — если у нас приложение внутри докера, то он опять же внешний получается компонент.
Как проверять и тестировать конфигурации девопс пайплайнов — это вообще отдельный, параллельный набор практик и гайдов, включая соображения того порядка что урл базы может поменяться или быть недоступным, потому что айпи адрес на AWS отвалился, или докер не стартует внутри нашего контейнер сервиса потому что опять что нибудь. И это все не проверить интеграционными тестами, это иллюзия. Это PaaS, который курируется и верифицируется иначе
как выше уже заметили, вам просто нужно отделить кафку от бизнес логики, и тогда вы обойдетесь тривиальными настройками. Более того, эта настройка становится единообразной для любых зависимостей, будь то рест, БД, кафка или что-то еще.
Обычно предлог для использования тестового контейнера или иного сложного мока состоит в том, что он содержит какую-то логику, которую хотелось бы сохранить и поменять которую нет возможности. Ну, типа, послал сообщение - в ответ приехало сообщение и т.п. Но даже в этом случае легче написать простой фейковый кафка провайдер, который будет отражать логику, которую вы ожидаете от реальной зависимости.
Спасибо большое за статью, очень здорово видеть ТДД, и кажется очевидным, что это делает код чище.
В имплементации же многое можно улучшить. Разница между given и when в том, что одно предусловие, а второе условие, и если предусловия мы принимает как есть, то в условии мы проверяем все кейсы, в этом сила конвенции.
Ну, скажем, вот у вас куча отдельных given'ов и одинаковые when'ы. Тут должно быть что-то вроде
givenModuleAndFactoryAndTempDir - потому что вы полагаетесь на их существование,
whenDependencyExcluded - а тут мы проверяем все случаи
Или вот еще пример
Тут тоже явно перебираются условия в given.
Ну и когда я вижу условия, я автоматически начинаю искать пропущенные - где все корнер-кейсы-то, т.е. пустые и несуществующие папки, пустые или некомпилируемые файлы, частично компилируемые файлы и т.п.?
Если же вы все это уже проверили в других местах, значит это предусловие и должно быть обозначено в given.
Сила ТДД в том, что можно посмотреть на тесты и понять, как должен вести себя код и что пропущено, - но из этих тестов этого пока не понятно.
(Слова типа Is, Are можно опускать в заголовках и тестах, они не нужны).
Да без разницы особо. С точки зрения юнит-тестов и то, и другое - непокрываемый black box, для которого важно только соответствие инпута и аутпута.
Ну, юнит-тесты нужны не для тестирования алгоритмов сортировки, а для тестирования дыр в системе типов. Нуль-пойнтеры, непустые коллекции, валидация полей, off-by-one, business exceptions, cross-field validations - пример вашего кода не проверяет из этого ничего, кроме того, что вы таки передали параметры в send. Иначе юнит тестов стало бы в 5-10 раз больше - как юнит-тестам и положено.
Метод convertContentToEntityDescriptor можно вызвать отдельно и передать его результат в основной метод, тогда и Mockito не понадобится.
Заменять юнит-тесты на RnR нет никакой необходимости - мы не можем записывать отдельную кассету для каждого нуль-пойнтера.
У RnR безусловно есть ниша, но она не совсем там, где вы описываете. Я вижу два, как минимум кейса.
1) - легаси API. Например, в вашем случае если нам надо послать все через CrappyGenericLegacyService, который два бизнес-поля превращает в сто полей, содержит private static void methods, половину ошибок глотает, а половину выплевывает во внешний сервис, который содержит в качестве зависимости. Проверять все ассертами долго, юнит тестами не подлезть. Да мы часто и не знаем, что именно проверять, а знать, что из него послано - хотелось бы. В этом случае RnR подходит идеально - легаси меняется редко и его поведение, как правило, детерминировано.
2) - матмодели. Если на вход подается два датасета и десять параметров, а на выходе еще один датасет значений в 1000 - сетапить тяжело, и отдельными ассертами неудобно тестировать.
И в том, и в другом случае RnR не столько тестирует (у него нет given-when-then), сколько подтверждает поведение системы, поэтому достаточно happy path записать.
Ну и в имплементации тоже.
"банальная регулярка" для отсеивания недетерминированных фрагментов - сама по себе источник багов. Практичнее, хотя и дольше, действительно ручками вытащить и записать нужные фрагменты, и иметь полностью детерминированную чистую кассету.
вместо человеко-читаемости кассету гораздо удобнее читать машиной. Для длинной кассеты assertEquals неинформативен. Кассета должна быть diffable и automatable, и дифф просто возвращает номер первой неверной строки.
Важный аргумент в пользу конструкторов - возможность полностью убрать аннотации из бинов и вынести их в отдельные конфиг файлы. Тогда эти классы можно тестировать junit'ом независимо от спринга, держать отдельный конфиг для тестов и отдельный для приложения, или использовать в библиотеке отдельно
Утечки не подтверждены, поэтому наверное в заголовке должно быть "якобы из-за утечек".
Jetbrains — одна из крутейших компаний в мире, без всяких скидок. И да, могут себе позволить.
Очевидно, что следить и продавать юзерские данные гораздо легче, когда юзер сам себя залогинил.
Сравните, например, как выкатываются и обкатываются фичи на реакте.
Китайский в данном случае подход — скопировать идею без понимания и чтоб как будто просто. Там не один разработчик, а целое коммьюнити такое.
>> Кроме того, простота входа привлекает не самых лучших разработчиков — ага, ну давайте сделаем все через одно место, чтобы максимально усложнить всем работу.
нет, давайте установим правила, а не будем давать джуниорам гранаты
Интеграционные тесты приложения вместе с окружающей средой вредят и приложению, и окружающей среде. Индустрия в принципе движется туда, где эти вещи ортогональны.
Этому я совершенно не противоречу. Свой код покрывается юнитами, внешние контракты контрактными тестами, то бишь тестами зависимостей.
Мне показалось, что у вас есть избирательность в том, что тестировать, и прошу прощения, если это не так.
Я в интеграционных тестах концентрируюсь на:
— happy path
— очень ограниченное количество fail case
Дальше из эксплуатации станет понятно, какие кейсы в интеграционные тесты добавить.
Это знакомо, так девяносто процентов делает, т. е. фактически юзеры тестируют.
Тесты валидации, и вообще поведение выставленного API — проверяется в функциональных тестах. Но без деталей. Например для тестов валидации — проверяется что на конкретный запрос в результате инстацируется фабрикой конкретный валидатор и ему передается на валидацию конкретный объект. А все детали валидации тестируются в модульных тестах.
Это тоже знакомый подход — мы решили что будем экономить на тестах и поэтому тестировать только места со сложной логикой. Проблема этого подхода в том, что он inplementation driven. Сложный валидатор может быть следствием плохой разбивки на эндпойнты например. В этих случаях тестируемые места превращаются в логические чёрные дыры, насасывая все больше условий, а остальные части становятся номинальными.
Например, если валидаторы пишет одна команда. А использует их в конкретном сервисе, которые выставляет API, другая команда. Понятно, у первых могут быть свои тесты. Но вторым, чтобы быть уверенными в том, что все работает ожидаемым образом, могут быть свои тесты, реализованные на функциональном-интеграционном слое, которые могут повторять значительную часть логики тестов первой команды.
Если валидаторы пишет другая команда, то это означает, что у нас внешняя зависимость. Для тестирования внешней зависимости мы делаем интеграционный тест для зависимости, который берет внешний урл, это нормально и это единственный валидный кейс для интеграции. Но запускать систему целиком для этого необходимости нет.
Насчёт урла я не понимаю. Урл — это внешний параметр, тестировать его бесполезно. Работающий дев урл ничего не говорит о QA или продакшене.
Про докер я не знаю, что вы конкретно имеете ввиду — если у нас приложение внутри докера, то он опять же внешний получается компонент.
Как проверять и тестировать конфигурации девопс пайплайнов — это вообще отдельный, параллельный набор практик и гайдов, включая соображения того порядка что урл базы может поменяться или быть недоступным, потому что айпи адрес на AWS отвалился, или докер не стартует внутри нашего контейнер сервиса потому что опять что нибудь. И это все не проверить интеграционными тестами, это иллюзия. Это PaaS, который курируется и верифицируется иначе
Приведите пример какой нибудь, трудно абстрактно обсуждать