Детерминированность тестов. Ты один раз endpoint дернул - будет хороший результат, второй раз дёрнул - случилась внутренния ошибка чтения из серверного кеша. Но второй-пятый-десятый раз мало кто дергает.
Юнитовый тест проверяет более мелкие кусочки, и такие вещи как чтение из кеша будет одним из обязательных шагов.
Но в вашем конкретном случае достаточно было бы использовать async enumerable, и было бы точно так же минималистично, как и в примере с go. Ну только, разумеется, более читаемо :)
Сперва была речь про "что с моими данными на фронте", а теперь уже "как и зачем используется модуль". Это разные вещи, не надо подменять понятия, мы здесь не любим демагогию.
Знать, как и зачем используется - очень маленькая информация, буквально достаточно пары предложения, описывающих потребляемый продукт. Это настолько легко, что сложнее этого специально пытаться не узнать.
А вот после того, как данные на фронт отданы, то знать как он их там крутит-вертит-сортирует -- нафига это бекенду? Какого цвета там кнопка (с текстом от бекенда) -- такой же вопрос.
В таком случае обезьяны напечатают войну и мир практически со стопроцентной вероятностью чуть ли не с первого раза. Ведь для каждого индекса нужной строки существует всего около сотни вариантов с единственным правильным, а обезьян, одновременно жмакающих рандомную клавишу, в условии сильно, сильно больше сотни.
Я просто указываю на тот факт, что они существуют, могут быть написаны не нами и не быть нам подконтрольными, т.е. существовать внутри nuget-пакета, например
В таком случае, это плохие пакеты, которые плохо спроектировали. Подобный аргумент можно и раздуть дальше — например, можно сказать, что, могут существовать такие пакеты, которые складывают статичные данные вообще в файл рядом с собой. Или еще куда. Что вы будете с ними делать, вмето пересоздания процесса перезапускать весь контейнер? Или всё же признаете, что это не проблема stateless хоста?
Мне кажется, вы как-то не так понимаете stateless/serverless. Из ваших претензий я почерпываю следующее:
Вы хотите, чтобы все статические классы магически обнулились. Но, надеюсь, вы понимаете, что магии не бывает, плюс (также надеюсь) вы знаете как работает .NET, и следовательно понимаете, что для этого обнуления потребуется пересоздать AppDomain (если уж не перезапускать весь процесс).
Вы также хотите, чтобы стартап "stateless" происходил максимально быстро и негодуете на медленную скорость подъёма приложения.
Но я не вижу, как именно вы подразумеваете, как это должно произойти. Возможно, через множество подготовленных одноразовых аппдоменов? Но ведь это же ужасно расточительно, тратить 100+мс процессора, чтобы выполнить один очень быстрый и не требовательный ресурс.
Еще одно противоречение вижу в ваших словах: вы противитесь не использованию стататичных классов, но топите за "stateless". Закономерный вопрос - нафига вам статичные классы, если, по вашей логике, в "stateless" вы ожидаете, что они будут постоянно обнуляться (что довольно дорого со стороны хоста)? У вас есть ваш хендлер-метод, есть весь контекст запроса, зачем вам статика?
Понимаете к чему я, или начнёте спрашивать, мол, ну а нестатичная переменная типа тоже почему не обнулялась?
Боюсь вас снова разочаровать, но вы неправильно протестировали. Моё решение не модифицирует магически поведение статичных классов. И не предполагает, что вы будете их использовать (так же, как бы вы не использовали их в обычной современной архитектуре любого приложения).
На мой взгляд, добавление такой абстракции и регистрация сервисов в serverless-приложениях делает их слишком тяжеловесными. И это мы ещё не зарегистрировали и не использовали ни одного сервиса, просто добавили для них обёртку.
Если вам не нужны сервисы, то вы их просто не регистрируйте. Но если (в контексте вашеих задач) они вам нужны, то вам в любом случае от них никуда не деться, с учетом того, что выше приложение постоянно выключают. Т.е. этот аргумент не играет ни в чью пользу.
когда вызовы происходят настолько часто, что подготовленный экземпляр существует всегда. Но в таком случае разработчик скорее всего захочет максимально оптимизировать время работы функции и будет наоборот отказываться от любых дополнительных абстракций.
Не понял. Если у вас долгоживущее приложение (из-за частых запросов), то регистрация сервисов (=стартап) как раз будет происходить лишь единожды.
Естественных увлажнителей два - мокрый "радиатор" с вентилятором и "кипятильник".
Вентиляторный по мощности не сильно больше жрёт ультразвукового, но зато в нём разножается всякое г-но.
Кипятильник же г-ну размножаться не даёт, но жрёт больше всех.
Осторожно, у вас двойное отрицание.
Именно бизнес-логику и надо тестировать. Уточню лишь, что "бизнес" подразумевается в контексте кода/приложения, а не заказчика.
А в случае с упавшей крышей это как раз и есть UI тест. Интеграционных, при хороших, правильных юнитах (а не "все подряд"), почти не требуется.
Ну вот. А если всё хорошенько покрыть юнитами, то интеграционные уже особо ничего не порешают. Уже нужен будут более верхние по пирамиде. ^^
Детерминированность тестов. Ты один раз endpoint дернул - будет хороший результат, второй раз дёрнул - случилась внутренния ошибка чтения из серверного кеша. Но второй-пятый-десятый раз мало кто дергает.
Юнитовый тест проверяет более мелкие кусочки, и такие вещи как чтение из кеша будет одним из обязательных шагов.
Но ведь интеграционные тесты, пусть и покрывающие все кейсы, не гарантируют детерминированности, в отличии от юнитовых.
Так и как же всё-таки сделать Unit-тестирование в .NET проще и интереснее?
Но в вашем конкретном случае достаточно было бы использовать async enumerable, и было бы точно так же минималистично, как и в примере с go. Ну только, разумеется, более читаемо :)
Сперва была речь про "что с моими данными на фронте", а теперь уже "как и зачем используется модуль". Это разные вещи, не надо подменять понятия, мы здесь не любим демагогию.
Знать, как и зачем используется - очень маленькая информация, буквально достаточно пары предложения, описывающих потребляемый продукт. Это настолько легко, что сложнее этого специально пытаться не узнать.
А вот после того, как данные на фронт отданы, то знать как он их там крутит-вертит-сортирует -- нафига это бекенду? Какого цвета там кнопка (с текстом от бекенда) -- такой же вопрос.
Видимо, в первую очередь стали уходить сеньоры, на которых все держалось.
В таком случае обезьяны напечатают войну и мир практически со стопроцентной вероятностью чуть ли не с первого раза. Ведь для каждого индекса нужной строки существует всего около сотни вариантов с единственным правильным, а обезьян, одновременно жмакающих рандомную клавишу, в условии сильно, сильно больше сотни.
Божечки, да это вот "безразлично" на беке существует в каждом слое, между слоями, и вообще называется слабой связностью.
Вот ты и попался.
Ох уж эти свидетели "ии зохватет мир".
Мне кажется, что так уже никто не делает. Данные утеряются при рестарте же.
Но если при этом корзина будет в БД, то это уже не состояние?
Лайк за шрифт консоли
В таком случае, это плохие пакеты, которые плохо спроектировали. Подобный аргумент можно и раздуть дальше — например, можно сказать, что, могут существовать такие пакеты, которые складывают статичные данные вообще в файл рядом с собой. Или еще куда. Что вы будете с ними делать, вмето пересоздания процесса перезапускать весь контейнер? Или всё же признаете, что это не проблема stateless хоста?
Мне кажется, вы как-то не так понимаете stateless/serverless. Из ваших претензий я почерпываю следующее:
Вы хотите, чтобы все статические классы магически обнулились. Но, надеюсь, вы понимаете, что магии не бывает, плюс (также надеюсь) вы знаете как работает .NET, и следовательно понимаете, что для этого обнуления потребуется пересоздать AppDomain (если уж не перезапускать весь процесс).
Вы также хотите, чтобы стартап "stateless" происходил максимально быстро и негодуете на медленную скорость подъёма приложения.
Но я не вижу, как именно вы подразумеваете, как это должно произойти. Возможно, через множество подготовленных одноразовых аппдоменов? Но ведь это же ужасно расточительно, тратить 100+мс процессора, чтобы выполнить один очень быстрый и не требовательный ресурс.
Еще одно противоречение вижу в ваших словах: вы противитесь не использованию стататичных классов, но топите за "stateless". Закономерный вопрос - нафига вам статичные классы, если, по вашей логике, в "stateless" вы ожидаете, что они будут постоянно обнуляться (что довольно дорого со стороны хоста)? У вас есть ваш хендлер-метод, есть весь контекст запроса, зачем вам статика?
Понимаете к чему я, или начнёте спрашивать, мол, ну а нестатичная переменная типа тоже почему не обнулялась?
Боюсь вас снова разочаровать, но вы неправильно протестировали. Моё решение не модифицирует магически поведение статичных классов. И не предполагает, что вы будете их использовать (так же, как бы вы не использовали их в обычной современной архитектуре любого приложения).
Если вам не нужны сервисы, то вы их просто не регистрируйте. Но если (в контексте вашеих задач) они вам нужны, то вам в любом случае от них никуда не деться, с учетом того, что выше приложение постоянно выключают. Т.е. этот аргумент не играет ни в чью пользу.
Не понял. Если у вас долгоживущее приложение (из-за частых запросов), то регистрация сервисов (=стартап) как раз будет происходить лишь единожды.