Вот и мне интересно. Какую проблему для простых людей, блокчейн сам или решение основанное на блокчейне решает лучше, чем существующие сегодня их альтернативы.
Тут стоит пояснить, что я имел ввиду под "возможностью доступа к приватным полям и методам". Очевидно, этот доступ нужен без создания публичных методов только для целей тестирования.
Т.е. полезно для тестов иметь доступ к действительно приватным методам и полям.
Скажем, модульные тесты непосредственно связаны с тестируемым кодом. И хозяин у рабочего кода и модельных тестов, как правило один. И жизненный цикл тестов и рабочего кода подчинен одинаковым приоритетам.
Тесты, о которых Вы пишете - то, к чему надо стремиться. В рафинированном виде такие встречаются только в обучающих материалах по TDD. В жизни обычно приходишь на новый проект, смотришь на юнит тесты и ужасаешься. В некоторых компаниях их до сих пор вообще не применяют.
Это все так.
И эксперименты проводить полезно.
Но такое ощущение, что люди забывают, что требования к рабочему коду и коду тестов - разные. Все то, что хорошо для рабочего кода, далеко не всегда хорошо для тестового кода. И наоборот.
Уважаемые разработчики! Используйте данные примеры, только для изучения принципов работы со Stream API. На реальных проектах использовать эти примеры для фильтрации данных из БД категорически не нужно.
Ну справедливости ради, таки разрывы цепочек поставок присутствуют.
В итоге, одни не могут продать, и у них склады забиты готовой продукцией. Другие купить, и у них опять же склады забиты, но только неготовой продукцией.
Возможно это будет новостью, но современные переводы через традиционные каналы (Банки, и прочие Вестерн Юнионы, Золотые короны) работают ровно так, как описано выше.
Когда вы принесли, допустим на почту, свои деньги и отправили почтовым переводом, никто не отправляет ваши деньги ни физически, ни виртуально в другое отделение. Они фактически остаются в отделении. А в другом отделении выдаются чужие деньги.
И раз в день, или в раз в неделю, или раз в любой другой удобный период, между отделениями происходит взаиморасчет. Ровно так, так это описано выше.
Вся соль, только в том, как происходит взаиморасчет. Банки - через центр обмена платежами, либо напрямую. Вестерн или Золотая корона - сами по себе центры обмена платежами.
Но для меня важный критерий для тестов - может ли посторонний человек посмотреть на код теста, на результат теста и через 10-30 секунд сказать что тест проверяет, и почему он сломался. Пусть даже с не 100% точностью.
Вот смотрю я на код тестов, и понимаю, что даже примерно ответить на такой вопрос сложно. Без погружения к предметную область данного конкретного теста.
Академически считается правильным, что сервис самостоятельно проверяет все гранты по запросу. А у API Gateway две ответственности: отделить авторизованную зону от неавторизованной, и иногда обогатить запрос приватной информацией, которую не хочется светить в jwt-токене. Конечно, это не аксиома, и при понимании что делаешь, можно от нее отклоняться.
Для тестирования такого кода стоит использовать публичные методы класса. Юнит-тест – это такой же клиент основного кода, как и остальные, для него не должно быть привилегий дополнительного доступа к тестируемой системе по сравнению с обычным клиентским кодом.
Скорее наоборот.
Возможность доступа к приватным полям и методам, крайне упрощает тестирование.
Есть, конечно, BlackBox тестирование, но его польза сильно ограничена.
Так и не понял, зачем нам средне-арифметическое, если сервис зависит от прочих сетевых сервисов, и БД. Большая часть ожидания будет от сети. А если мерить работу всех компонент, то надо разворачивать максимально приближенно к проду. Т.е. стартуем приложение, а не внутри jmh гоняем маленький кусок кода.
Насколько я понимаю, проблема с торможением сервиса вызвана тормозами БД-х и зависимых сетевых сервисов.
Соответственно, мы меняем логику работы нашего сервиса, чтобы уменьшить зависимость от замедления наших зависимостей. И соответственно нам нужны не JMH тесты, а юнит тесты, которые воспроизводят ситуации:
зависимые сервисы работают с соблюдением SLO, значит мы получаем данные из них, и наш SLA не нарушается
зависимые сервисы работают с нарушением SLO, значит мы включаем альтернативу, например, получаем данные из кешей, и опять же наш SLA не нарушается.
При этом использование нагрузочных тестов (пусть даже JMH, хотя и странно ;) тоже полезно, чтобы убедиться, что помимо правильной логики, сервис не падает под нагрузкой.
Честно говоря так и не понял, почему считается, что брокер сообщений может терять сообщения, а БД не может терять данные.
В общем случае, если проблемы на инфраструктуре, то данные может терять и брокер, и БД.
В вашем случае, вы создали два гетерогенных персистентных хранилища вместо одного. Два лучше одного, в смысле надежности, это бесспорно. А как называется подход (outbox), уже неважно.
stackoverflow detectedВот и мне интересно. Какую проблему для простых людей, блокчейн сам или решение основанное на блокчейне решает лучше, чем существующие сегодня их альтернативы.
configuration-as-a-code же...
Т.е. если кто-то оптимизирует производство полимеров, которые существенно улучшают лечебные свойства лекарств-мазей - это не биотех?
Если кто-то оптимизирует антибиотики - это не биотех?
ну и т.д.
Тут стоит пояснить, что я имел ввиду под "возможностью доступа к приватным полям и методам". Очевидно, этот доступ нужен без создания публичных методов только для целей тестирования.
Т.е. полезно для тестов иметь доступ к действительно приватным методам и полям.
Хрупкость - понятие относительное.
Скажем, модульные тесты непосредственно связаны с тестируемым кодом. И хозяин у рабочего кода и модельных тестов, как правило один. И жизненный цикл тестов и рабочего кода подчинен одинаковым приоритетам.
В этом случае, как таковой хрупкости нет.
Это все так.
И эксперименты проводить полезно.
Но такое ощущение, что люди забывают, что требования к рабочему коду и коду тестов - разные. Все то, что хорошо для рабочего кода, далеко не всегда хорошо для тестового кода. И наоборот.
почему считается, что зависнуть или потеряться по дороге может только в банке или свифте?
у оригинальной хавалы нет обмена информацией? каналы гарантированно не теряют информацию? участники не пытаются обмануть?
Не увидел как проводили тесты, чем меряли, какие сайты были в выборке, как анализировали результаты. и т.д.
По моему забыли добавить такое предупреждение:
Уважаемые разработчики! Используйте данные примеры, только для изучения принципов работы со Stream API. На реальных проектах использовать эти примеры для фильтрации данных из БД категорически не нужно.
Ну справедливости ради, таки разрывы цепочек поставок присутствуют.
В итоге, одни не могут продать, и у них склады забиты готовой продукцией. Другие купить, и у них опять же склады забиты, но только неготовой продукцией.
Возможно это будет новостью, но современные переводы через традиционные каналы (Банки, и прочие Вестерн Юнионы, Золотые короны) работают ровно так, как описано выше.
Когда вы принесли, допустим на почту, свои деньги и отправили почтовым переводом, никто не отправляет ваши деньги ни физически, ни виртуально в другое отделение. Они фактически остаются в отделении. А в другом отделении выдаются чужие деньги.
И раз в день, или в раз в неделю, или раз в любой другой удобный период, между отделениями происходит взаиморасчет. Ровно так, так это описано выше.
Вся соль, только в том, как происходит взаиморасчет. Банки - через центр обмена платежами, либо напрямую. Вестерн или Золотая корона - сами по себе центры обмена платежами.
Без обид.
Но для меня важный критерий для тестов - может ли посторонний человек посмотреть на код теста, на результат теста и через 10-30 секунд сказать что тест проверяет, и почему он сломался. Пусть даже с не 100% точностью.
Вот смотрю я на код тестов, и понимаю, что даже примерно ответить на такой вопрос сложно. Без погружения к предметную область данного конкретного теста.
Сильно зависит от вашего контекста.
Академически считается правильным, что сервис самостоятельно проверяет все гранты по запросу. А у API Gateway две ответственности: отделить авторизованную зону от неавторизованной, и иногда обогатить запрос приватной информацией, которую не хочется светить в jwt-токене. Конечно, это не аксиома, и при понимании что делаешь, можно от нее отклоняться.
Скорее наоборот.
Возможность доступа к приватным полям и методам, крайне упрощает тестирование.
Есть, конечно, BlackBox тестирование, но его польза сильно ограничена.
Это вообще антипаттерн для хайлоад, никак не могу отучить разрабов от его использования.
Так и не понял, зачем нам средне-арифметическое, если сервис зависит от прочих сетевых сервисов, и БД. Большая часть ожидания будет от сети. А если мерить работу всех компонент, то надо разворачивать максимально приближенно к проду. Т.е. стартуем приложение, а не внутри jmh гоняем маленький кусок кода.
Насколько я понимаю, проблема с торможением сервиса вызвана тормозами БД-х и зависимых сетевых сервисов.
Соответственно, мы меняем логику работы нашего сервиса, чтобы уменьшить зависимость от замедления наших зависимостей. И соответственно нам нужны не JMH тесты, а юнит тесты, которые воспроизводят ситуации:
зависимые сервисы работают с соблюдением SLO, значит мы получаем данные из них, и наш SLA не нарушается
зависимые сервисы работают с нарушением SLO, значит мы включаем альтернативу, например, получаем данные из кешей, и опять же наш SLA не нарушается.
При этом использование нагрузочных тестов (пусть даже JMH, хотя и странно ;) тоже полезно, чтобы убедиться, что помимо правильной логики, сервис не падает под нагрузкой.
Честно говоря так и не понял, почему считается, что брокер сообщений может терять сообщения, а БД не может терять данные.
В общем случае, если проблемы на инфраструктуре, то данные может терять и брокер, и БД.
В вашем случае, вы создали два гетерогенных персистентных хранилища вместо одного. Два лучше одного, в смысле надежности, это бесспорно. А как называется подход (outbox), уже неважно.
Ок достаточно, в случае если банк берет на себя обязательство при отсутствии Ок, позвать повторно.