Так получается, что расчет переложен на отдельный «микро-сервис». Насколько я понял, на сервер не хотели перекладывать обязанность подсчета, потому что пришлось бы менять протокол общения с клиентом. А так получается протокол остается старым, но при этом расчет происходит на сервере.
Куча читеров может всех унижать (как писали выше в комментариях)
А я тут подумал, а что если зарегистрировать служебного пользователя, захостить его где-нибудь на сервере и подключать к каждой игре? Получается он смог бы, как текущие клиенты, отслеживать все действия в игре и отправлять данные на сервер. А на сервере сделать, чтобы он доверял только этому специальному клиенту и при этом не показывал его присутствие остальным участникам. Это бы решило предыдущие проблемы.
Как я уже написал раньше, если бы я тестировал получения ранодомного чесла — я бы вызвал метод большое количество раз (например 10 тысяч), затем проверил бы, что все числа находятся в заданных пределах и что распределение близко к равномерному. При этом, разумеется, тест может оказаться не очень стабилен (все таки это рандом). Но стабильность можно улучшить увеличив число вызовов.
В данном примере, если не мокать получение рандомного числа — то, логически, мы уже начинаем тестировать метод получения рандомного числа. А это задача довольно нетривиальная, нужно проводить много испытаний и смотреть распределение. Не лучше ли реализовать тестирование получения рандомного числа в классе получения рандомного числа?
А этот метод я бы вообще тестами не покрывал, ибо он не содержит логики. А если бы он содержал логику, завязанную на рандомные числа, то я бы предпочел замокать рандом, тем самым упростив тест и сделав его стабильным. Здесь, очевидно, нужен компромис.
Что я хотел сказать: данный пример, на мой взгляд, не защищает точку зрения, изложенную в статье :)
Я думаю это плохой тест. Предположим произошла ошибка и рандом стал возвращать числа до 10 включительно. О такой ошибке тест может сообщить очень не скоро.
Дорогостоящая? <...> первые 10 строк GUI-тестов заменят первые десять тысяч строк юнит-тестов.
Суть автоматизации тестирования в сокращении времени между появлением бага и его обнаружением. В случае юнит теста вы узнаете о баге еще до коммита. И вы будете с точностью до метода знать, где находится проблема. В случае GUI теста в лучшем случае сценарий будет такой:
1. Разработчик сделает пул реквест
2. Другой разработчик его посмотрит и зааппрувит
3. Сработает какой-либо триггер сборки новой версии (будь то наличие изменений в репозитории или просто ночью в определенное время)
4. Где-нибудь сразу после сборки пойдут тесты и упадут (и, вероятно, отправят письмецо «команде автоматизации»)
5. Через некоторый промежуток времени у автоматизатора появится время посмотреть в чем проблема. Он, скорее всего попробует воспроизвести проблему локально чтобы убедиться, что проблема не в тесте (а тесты довольно нестабильная штука, что бы вы не говорили о ленивости их разработчиков)
6. Убедившись, что это действительно проблема в продукте, тестировщик пойдет заводить баг
7. Баг попадает в бэклог (или еще какое-то хранилище, где он будет ждать пока его починят)
8. Разработчик через некоторое время доберется до бага.
9. Из бага не всегда можно понять где именно проблема, поэтому некоторое время разработчик потратит на отладку
10. После этого баг будет пофикшен и пул реквест снова отправится на код ревью
И далеко не факт, что после правки этого бага не появилось новых двух ;)
Поэтому да. Дорогостоящая как по трудовым ресурсам, так и по времени обнаружения и устранения
Решить-то их можно на чем угодно. Вопрос в количестве потраченного времени и в объеме кода. И что-то мне подсказывает, что Java и C# уступят по этим критериям питону для этих задач. Тут следует обратить внимание, что в приведенных задачах не требуется слишком высокая производительность, что и служит знаком к использованию питона.
Вы говорите так, будто один человек не может и играть в мяч, и собирать покемонов. Я вот, например, не гонял мяч ни до появления покемонов, ни после. Однако теперь вместо того, чтобы смотреть глупые видео на YouTube, я хожу по городу, что полезно как минимум в виде физического упражнения.
Да, уязвимости с непосредственным доступом к машине — это не так страшно, как удаленные атаки. Но пароль на грабе, насколько мне известно, единственный способ избежать вот этой проблемы. А теперь оказывается, что и он уязвим. Получается, что если ты используешь grub2 — ты даешь рутовый доступ любому, что получил непосредственный доступ к твоей машине.
Одно дело положить вирусняк, а другое дело — его исполнить. Более или менее осведомленный в области IT пользователь не станет запускать непонятный exe-шник, а вот docx файл на первый взгляд не кажется опасным. А если в сетевой папке 40+ файлов, то dll там запросто затеряется.
Ни в коем случае не хочу оправдывать преступников, но вашу аналогию я считаю не точной. Я бы скорее проассоциировал их с продавцами отмычек или оружия. Т.е. сами они своей торговлей непосредственно никому не вредят, все вредоносные действия остаются на совести покупателей.
На сколько я понял, мы условились, что в интерфейсе не будет свойства Color. Однако в блоке кода под заголовком «Применение посетителя к задаче» это свойство в интерфейсе есть. Я что-то не правильно понял?
Работаю на аутсорсе, поступила такая задача. По каким-то не известным мне причинам компания всячески старается избегать использования сторонних библиотек.
Если ориентация треугольников заранее известна (а во многих алгоритмах это так), можно подобрать знаки заранее, они останутся верными.
Проблема в том, что мы не знаем заранее, какой треугольник слева, а какой справа. При этом в зависимости от положения треугольника знак синуса меняется, а знак косинуса нет. Получается, что в зависимости от того, какой угол мы обозначим за альфа, меняется результат всего выражения, что не очень хорошо)
По поводу оптимизации вы правы, я почему-то об этом не задумывался.
А в чём польза проверки двумерного условия Делоне для решения задачи триангуляции трёхмерного облака? Разве там не нужно строить альфа-сеть по трёхмерному аналогу триангуляции?
Я создавал модель поверхности, а эта задача сводится к двухмерной триангуляции т.к. глубину точки на время триангуляции можно опустить.
У этого варианта минимум два минуса:
А я тут подумал, а что если зарегистрировать служебного пользователя, захостить его где-нибудь на сервере и подключать к каждой игре? Получается он смог бы, как текущие клиенты, отслеживать все действия в игре и отправлять данные на сервер. А на сервере сделать, чтобы он доверял только этому специальному клиенту и при этом не показывал его присутствие остальным участникам. Это бы решило предыдущие проблемы.
А этот метод я бы вообще тестами не покрывал, ибо он не содержит логики. А если бы он содержал логику, завязанную на рандомные числа, то я бы предпочел замокать рандом, тем самым упростив тест и сделав его стабильным. Здесь, очевидно, нужен компромис.
Что я хотел сказать: данный пример, на мой взгляд, не защищает точку зрения, изложенную в статье :)
Я думаю это плохой тест. Предположим произошла ошибка и рандом стал возвращать числа до 10 включительно. О такой ошибке тест может сообщить очень не скоро.
Суть автоматизации тестирования в сокращении времени между появлением бага и его обнаружением. В случае юнит теста вы узнаете о баге еще до коммита. И вы будете с точностью до метода знать, где находится проблема. В случае GUI теста в лучшем случае сценарий будет такой:
1. Разработчик сделает пул реквест
2. Другой разработчик его посмотрит и зааппрувит
3. Сработает какой-либо триггер сборки новой версии (будь то наличие изменений в репозитории или просто ночью в определенное время)
4. Где-нибудь сразу после сборки пойдут тесты и упадут (и, вероятно, отправят письмецо «команде автоматизации»)
5. Через некоторый промежуток времени у автоматизатора появится время посмотреть в чем проблема. Он, скорее всего попробует воспроизвести проблему локально чтобы убедиться, что проблема не в тесте (а тесты довольно нестабильная штука, что бы вы не говорили о ленивости их разработчиков)
6. Убедившись, что это действительно проблема в продукте, тестировщик пойдет заводить баг
7. Баг попадает в бэклог (или еще какое-то хранилище, где он будет ждать пока его починят)
8. Разработчик через некоторое время доберется до бага.
9. Из бага не всегда можно понять где именно проблема, поэтому некоторое время разработчик потратит на отладку
10. После этого баг будет пофикшен и пул реквест снова отправится на код ревью
И далеко не факт, что после правки этого бага не появилось новых двух ;)
Поэтому да. Дорогостоящая как по трудовым ресурсам, так и по времени обнаружения и устранения
По поводу оптимизации вы правы, я почему-то об этом не задумывался.
Я создавал модель поверхности, а эта задача сводится к двухмерной триангуляции т.к. глубину точки на время триангуляции можно опустить.