Почему нельзя сканировать? Можно же, абсолютно безопасно. Как и переходить по любым ссылкам. И даже скачивать ехе и apk. Это все само по себе ничего с вами не сделает.
Детерминированность тестов. Ты один раз endpoint дернул - будет хороший результат, второй раз дёрнул - случилась внутренния ошибка чтения из серверного кеша. Но второй-пятый-десятый раз мало кто дергает.
Юнитовый тест проверяет более мелкие кусочки, и такие вещи как чтение из кеша будет одним из обязательных шагов.
Но в вашем конкретном случае достаточно было бы использовать async enumerable, и было бы точно так же минималистично, как и в примере с go. Ну только, разумеется, более читаемо :)
Сперва была речь про "что с моими данными на фронте", а теперь уже "как и зачем используется модуль". Это разные вещи, не надо подменять понятия, мы здесь не любим демагогию.
Знать, как и зачем используется - очень маленькая информация, буквально достаточно пары предложения, описывающих потребляемый продукт. Это настолько легко, что сложнее этого специально пытаться не узнать.
А вот после того, как данные на фронт отданы, то знать как он их там крутит-вертит-сортирует -- нафига это бекенду? Какого цвета там кнопка (с текстом от бекенда) -- такой же вопрос.
В таком случае обезьяны напечатают войну и мир практически со стопроцентной вероятностью чуть ли не с первого раза. Ведь для каждого индекса нужной строки существует всего около сотни вариантов с единственным правильным, а обезьян, одновременно жмакающих рандомную клавишу, в условии сильно, сильно больше сотни.
Сами вы ей очевидно точно не занимаетесь, я смотрю.
Что за нулевая передача знаний, fingerprint.js?
Почему нельзя сканировать? Можно же, абсолютно безопасно. Как и переходить по любым ссылкам. И даже скачивать ехе и apk. Это все само по себе ничего с вами не сделает.
Для особо одаренных людей, которые ищут поисковик в поисковике.
Для пулла объекты скорее должны иметь некие
InitиReset, чем конструктор без конкретной пользы.А можно не 500? Звучит интересно уже сейчас.
А доказать, что эффективен для любого подходящего случая?
Будет потреблять как кипятильник, но с эффектом x0.01 от вентиляторного.
Естественных увлажнителей два - мокрый "радиатор" с вентилятором и "кипятильник".
Вентиляторный по мощности не сильно больше жрёт ультразвукового, но зато в нём разножается всякое г-но.
Кипятильник же г-ну размножаться не даёт, но жрёт больше всех.
Осторожно, у вас двойное отрицание.
Именно бизнес-логику и надо тестировать. Уточню лишь, что "бизнес" подразумевается в контексте кода/приложения, а не заказчика.
А в случае с упавшей крышей это как раз и есть UI тест. Интеграционных, при хороших, правильных юнитах (а не "все подряд"), почти не требуется.
Ну вот. А если всё хорошенько покрыть юнитами, то интеграционные уже особо ничего не порешают. Уже нужен будут более верхние по пирамиде. ^^
Детерминированность тестов. Ты один раз endpoint дернул - будет хороший результат, второй раз дёрнул - случилась внутренния ошибка чтения из серверного кеша. Но второй-пятый-десятый раз мало кто дергает.
Юнитовый тест проверяет более мелкие кусочки, и такие вещи как чтение из кеша будет одним из обязательных шагов.
Но ведь интеграционные тесты, пусть и покрывающие все кейсы, не гарантируют детерминированности, в отличии от юнитовых.
Так и как же всё-таки сделать Unit-тестирование в .NET проще и интереснее?
Но в вашем конкретном случае достаточно было бы использовать async enumerable, и было бы точно так же минималистично, как и в примере с go. Ну только, разумеется, более читаемо :)
Сперва была речь про "что с моими данными на фронте", а теперь уже "как и зачем используется модуль". Это разные вещи, не надо подменять понятия, мы здесь не любим демагогию.
Знать, как и зачем используется - очень маленькая информация, буквально достаточно пары предложения, описывающих потребляемый продукт. Это настолько легко, что сложнее этого специально пытаться не узнать.
А вот после того, как данные на фронт отданы, то знать как он их там крутит-вертит-сортирует -- нафига это бекенду? Какого цвета там кнопка (с текстом от бекенда) -- такой же вопрос.
Видимо, в первую очередь стали уходить сеньоры, на которых все держалось.
В таком случае обезьяны напечатают войну и мир практически со стопроцентной вероятностью чуть ли не с первого раза. Ведь для каждого индекса нужной строки существует всего около сотни вариантов с единственным правильным, а обезьян, одновременно жмакающих рандомную клавишу, в условии сильно, сильно больше сотни.
Божечки, да это вот "безразлично" на беке существует в каждом слое, между слоями, и вообще называется слабой связностью.