Ну, как мы уже обсуждали, само по себе сканирование в данном случае не может обходиться дорого любопытствующим с технической точки зрения, потому что для сканирования они используют ваши же собственные ресурсы. Следовательно, решение проблемы лежит либо в политике (наказаниях рублём особо любопытных, что, впрочем, не очень-то реалистично), либо в весьма сложных (и опять же малореалистичных) манипуляциях, когда скрипт нужно автоматически переписывать так, чтобы наказание происходило когда этот скрипт попытается отправить данные.
Честно говоря, тут у меня не хватает компетенции для определения хорошего ответного вектора.
Ну в данном случае контратака будет несимметричная скорее. Например, не допускать скрипт к загрузке. Или не дать ему отправить результаты.
Ну и остальные, тут в комментариях уже много вариантов, вплоть до браузера в нескольких слоях виртуалок, как то яйцо из знаменитой сказки.
Обычно тесты на типы принимаемыемых и возвращаемых значений не пишут.
В таком случае, вы верите, что там нет багов.
по сути undefined behavior
Верно, а если у функции есть диапазоны значений, на которых она не определена, то эти диапазоны следует фиксировать и в документации, и тестами. Потому что никогда не известно, когда очередной джуниор с горящим взором (или я) решит часть диапазонов "починить", и поломает какой-нибудь хитрый патч, который как раз на неопределённость и рассчитывает.
Для сравнения, для функции
getLength: Iterable[any] => PositiveInt
из моего примера теми самыми средствами языка (которые мы не тестируем) гарантируется 100% определённость в рантайме, потому что проверки системы типов не позволяют коммитить в рантайм код, который мог вызвать неопределённое поведение. И "хитрых патчей" с ней в центре тоже не возникнет, что, опять же, благо.
Большинство тестов на принимаемые и возвращаемые значения — уже в большинстве статически типизированных языков. При увеличении гибкости можно переносить в систему типов гарантии самих значений.
Ну вообще, тесты генератора запроса SQL не должны полагаться на сравнение строк, как вы уже достаточно убедительно доказали (и это, вообще, следует из знания домена SQL), Иначе такие тесты действительно слишком легко поломать, и слишком тяжело поддерживать. Юнитом здесь не должен, соответственно, быть генератор целиком — учитывая, что сервис всё-таки создаёт запросы не из строк обычной конкатенацией, у него должна быть некая реализация AST, и некие правила её создания. В таком случае мы получаем уже две категории тестов:
проверки промежуточного AST при заданных параметрах. Именно то, что будет проверять наличие в запросе правильной проекции, правильных предикатов, объединений, etc.
проверки перевода отдельных компонентов AST в строку для разных диалектов SQL, которые ваш генератор поддерживает
Насколько мне известно, большинство развитых библиотек генерации запросов такую структуру тестов и имеют. Юниты это всё или нет — вопрос для меня открытый, но сама необходимость таких тестов в некоторой долгосрочной перспективе — под вопросом вообще не стоит. Если же у вас вообще нет никаких долгосрочных планов на такой генератор — вам определённо не стоит его и писать, берите сразу готовый, у него скорее всего уже есть и написанные тесты.
А там нет универсальной стороны, что самое интересное. Зато есть очень многоарная функция цены от длительности разработки, качества исполнителей, качества постановки задачи, кривой обучения исполнителей деталям требования и "что заказчик действительно имел в виду", погоды, да и один Яхве знает чего ещё. Нелинейная. И при этом большая часть её аргументов становятся исчислимыми только в некрологе проекта, да и точный вид уравнения неизвестен пока никому (или очень хорошо скрываем).
Да, у меня (и многих до меня, и многих после, я уверен) был уже где-то тут комментарий о том, что достаточно гибкая система типов позволяет вообще не писать некоторые классы юнит-тестов, потому что начинает включать эти классы по факту своего (системы типов) существования. Точнее, предоставляет централизованную реализацию таких тестов.
Большое количество вариантов создадут на основе искусственного интеллекта, что решит проблему списывания и «сливов».
Но ведь это сработает только для тестовых заданий с вариантами ответа, разве нет? А как же задания с развёрнутым ответом? Повернутся в очередной раз вспять и будут снова уменьшать их количество?
Да даже для заданий с вариантами — неужели придумали уже как генерировать правдоподобные неверные варианты? А чего тогда с миром не делятся — вон у Oracle и подобных им корпораций сертификации до сих пор людьми пишутся, хотя вроде лидеры по машобу.
Что забавно — термин означает Plain Old Java Object, и используется программистами на других языках именно в такой форме, хотя Java иногда и не пахнет.
Наверное от того, что никому не хочется всерьёз дропнуть оттуда "J".
Я вот все комментарии прочитал, — и неужели кроме меня никого не удивило, что книга с названием «Зачем мы спим: Новая наука о сне и сновидениях» имеет возрастной рейтинг 18+?
Почему такой рейтинг? Детям будет неинтересно? Или там обсуждаются эротические сны? Или книга с картинками (и именно поэтому — мировой бестселлер)?
Но если в таблетке не содержится действующего вещества (по любой причине), то таблетка — плацебо, так? Если концентрация мелатонина в таблетке, возможно, 0%, то такая таблетка — возможно, плацебо.
Всё сходится. И за уши тянуть пришлось только чуть-чуть.
Не согласен.
Когда вы прибавляете к дате один месяц, то вы прибавляете следующий месяц, а не средний.
Потому, для 31 января длина следующего месяца не 30, а 28 (29) дней, и именно 28 (29) дней и следует прибавить. Получим 28 (29) февраля.
var first = LocalDate.of(2019, JULY, 31);
var second = LocalDate.of(2019, DECEMBER, 30);
print(Period.between(first, second));
Выведет P4M30D, что очень близко с результатом после починки (т.к. P30D равен P4W2D). Может это и «неправильно» — но неправильно скорее думать об этой операции как о каноничном сложении. Зато теперь калькулятор выдаёт тот же ответ, что многие другие приложения (в частности, написанные на Java, да).
Не думаю, что эта поговорка отражает реальное положение дел. Брачные игры у людей намного сложнее, и инициатором бывает и женщина — просто они это делают больше намёками, потому что ну вот такой вот социальный контракт.
Но даже если и отражает полностью — мужчины, в среднем, намного менее разборчивы, чем женщины.
Если компьютер действительно завис, часы останавливаются. Если нет — то, собственно, нет. Следовательно, если часы не остановились, то компьютер не завис, и проблема в устройстве ввода. А по секундам остановку часов проверить можно быстрее, чем по минутам.
Допустим, в lsFusion мне не нужно
Значит ли это также и то, что я не могу этим заморочиться, так как эти процессы не находятся вне моего контроля?
Честно говоря, тут у меня не хватает компетенции для определения хорошего ответного вектора.
Ну и остальные, тут в комментариях уже много вариантов, вплоть до браузера в нескольких слоях виртуалок, как то яйцо из знаменитой сказки.
И ведь не так чтобы долго в общежитии жил, а приклеилась всё равно.
Скрипт сканера выполняется на вашей же машине. И чего вы добились бы если устроили такую атаку на собственное устройство?
В таком случае, вы верите, что там нет багов.
Верно, а если у функции есть диапазоны значений, на которых она не определена, то эти диапазоны следует фиксировать и в документации, и тестами. Потому что никогда не известно, когда очередной джуниор с горящим взором (или я) решит часть диапазонов "починить", и поломает какой-нибудь хитрый патч, который как раз на неопределённость и рассчитывает.
Для сравнения, для функции
из моего примера теми самыми средствами языка (которые мы не тестируем) гарантируется 100% определённость в рантайме, потому что проверки системы типов не позволяют коммитить в рантайм код, который мог вызвать неопределённое поведение. И "хитрых патчей" с ней в центре тоже не возникнет, что, опять же, благо.
Большинство тестов на принимаемые и возвращаемые значения — уже в большинстве статически типизированных языков. При увеличении гибкости можно переносить в систему типов гарантии самих значений.
https://habr.com/ru/post/431250/#comment_19426486
Ну вообще, тесты генератора запроса SQL не должны полагаться на сравнение строк, как вы уже достаточно убедительно доказали (и это, вообще, следует из знания домена SQL), Иначе такие тесты действительно слишком легко поломать, и слишком тяжело поддерживать. Юнитом здесь не должен, соответственно, быть генератор целиком — учитывая, что сервис всё-таки создаёт запросы не из строк обычной конкатенацией, у него должна быть некая реализация AST, и некие правила её создания. В таком случае мы получаем уже две категории тестов:
Насколько мне известно, большинство развитых библиотек генерации запросов такую структуру тестов и имеют. Юниты это всё или нет — вопрос для меня открытый, но сама необходимость таких тестов в некоторой долгосрочной перспективе — под вопросом вообще не стоит. Если же у вас вообще нет никаких долгосрочных планов на такой генератор — вам определённо не стоит его и писать, берите сразу готовый, у него скорее всего уже есть и написанные тесты.
А там нет универсальной стороны, что самое интересное. Зато есть очень многоарная функция цены от длительности разработки, качества исполнителей, качества постановки задачи, кривой обучения исполнителей деталям требования и "что заказчик действительно имел в виду", погоды, да и один Яхве знает чего ещё. Нелинейная. И при этом большая часть её аргументов становятся исчислимыми только в некрологе проекта, да и точный вид уравнения неизвестен пока никому (или очень хорошо скрываем).
Но ведь это сработает только для тестовых заданий с вариантами ответа, разве нет? А как же задания с развёрнутым ответом? Повернутся в очередной раз вспять и будут снова уменьшать их количество?
Да даже для заданий с вариантами — неужели придумали уже как генерировать правдоподобные неверные варианты? А чего тогда с миром не делятся — вон у Oracle и подобных им корпораций сертификации до сих пор людьми пишутся, хотя вроде лидеры по машобу.
Что забавно — термин означает Plain Old Java Object, и используется программистами на других языках именно в такой форме, хотя Java иногда и не пахнет.
Наверное от того, что никому не хочется всерьёз дропнуть оттуда "J".
Почему такой рейтинг? Детям будет неинтересно? Или там обсуждаются эротические сны? Или книга с картинками (и именно поэтому — мировой бестселлер)?
Просветите, пожалуйста.
Всё сходится. И за уши тянуть пришлось только чуть-чуть.
Когда вы прибавляете к дате один месяц, то вы прибавляете следующий месяц, а не средний.
Потому, для 31 января длина следующего месяца не 30, а 28 (29) дней, и именно 28 (29) дней и следует прибавить. Получим 28 (29) февраля.
Выведет
P4M30D, что очень близко с результатом после починки (т.к.P30DравенP4W2D). Может это и «неправильно» — но неправильно скорее думать об этой операции как о каноничном сложении. Зато теперь калькулятор выдаёт тот же ответ, что многие другие приложения (в частности, написанные на Java, да).Не думаю, что эта поговорка отражает реальное положение дел. Брачные игры у людей намного сложнее, и инициатором бывает и женщина — просто они это делают больше намёками, потому что ну вот такой вот социальный контракт.
Но даже если и отражает полностью — мужчины, в среднем, намного менее разборчивы, чем женщины.