У нас эта проблема на ревью решается=) Постоянно джунов прошу разбивать свои функции и давать им адекватные имена. В данном случае только строгий контроль может чему-то научить. И да, в случае джунов, имхо, пусть лучше мелкие функции пишут, багов в этом случае по статистике меньше.
Причем здесь надзоры какие-либо? Что из себя представляют собой большинство современных linux-дистрибутивов? Это как раз таки пакетный менеджер + репозиторий с рекоммендуемыми или нерекоммендуемыми пакетами. Кто выбирает какие пакеты можно безопасно устанавливать, а какие можно ставить только на свой страх и риск? Никто не запретит вам установить в убунту какой-нибудь странный пакет, но в стандартном репозитории его не появится
Предполагается что остальные классы тоже будут покрыты=).
То что один юнит будет вызывать другой юнит с заданными параметрами и нужное количество раз как раз таки удобно тестировать с помощью моков. Ну и интеграционные тесты никто не отменяет, просто не нужно оценивать покрытие на основе интеграционных тестов.
Думаю самый эффективный способ борьбы с данной проблемой — введение какой-либо сертификации на пакеты. То есть предполагаю возникновение какой-либо организации которая будет давать устанавливать оценку «надежности» пакета. Все что не обладает соответствующим сертификатом все еще можно использовать, но на свой страх и риск.
Этого далеко не достаточно. С npm никогда не работал, и не уверен что такой пример сработает, но думаю что должно: имеем пакет от которого зависит какой-нибудь http-сервер, проверяем наличие данного сервера в текущей установке и колбэками, манкипатчингом или еще какими-нибудь ухищрениями заставляем http-сервер добавить в кукисы пользователя те же переменные окружения.
Для защиты от таких атак нужно полностью изолировать пакеты и реализовать аутентификацию/авторизацию на уровне public API пакетов (фактически использовать пакеты в качестве микросервисов).
Хочу заметить еще один важный плюс изолированных тестов. В процессе разработки очень полезно использовать такую метрику как «покрытие кода». Проблема данной метрики в том, что она всегда врет. Если имеется 100% показатель покрытия кода, это всего лишь значит что мы прошлись по коду, но совершенно не значит что мы проверили его работоспособность. Имея неизолированный тест мы увеличиваем покрытие соседних юнитов, не проверяя их работоспособность. Наличие дублеров делает данную метрику чуть более «честной», так как мы вызываем только тестируемый код.
может в разных win версии сапера немного отличались? Я вот тоже обнаруживал данное поведение. Первое открытие клетки с 50% вероятностью натыкания на мину всегда было успешным, а последующие были уже честными. Я даже исследование некоторое проводил, рандомно тыкал в карту пока не натыкался на подобные случаи. Насколько я помню натыкаться на мины в такой ситуации с первого раза у меня выходило только при включении встроенного в сапер чита отображающего хитрым пикселем наличие мины.
Идея классная, причем даже реализация не должна быть слишком сложной. Но есть ряд сложностей с UI и UX ко всему этому делу. Например я не знаю как при этом будет отображаться процесс «листания» кода «стриммером» и нужно ли это отображать. Нужно ли позволять пользователю просматривать соседние файлы. Позволять ли пользователю использовать ctrl+click и не превращается ли весь этот процесс в совместную работу или парное программирование, потому что следующий шаг — позволение «зрителю» тоже писать код
> вы сделали некий функционал который использует 50% API фейсбука
ИМХО, в таком случае уже появляется другая проблема — selenium для таких целей не очень подходит.
Фактически мы проверяем что сторонний API работает так как мы ожидаем. В этом конечно нет ничего плохого, но в данном случае лично я бы проверял именно ответы API, а не работу системы с данным API.
PS: Я просто пытаюсь рассуждать, не сочтите что я с вами спорю.
> Используя mock не будем ли мы тестировать тестовую логику?
К сожалению, с mock'ами всегда имеется такая проблема=/ Мне вообще всегда довольно сложно дается ответ на вопрос использовать их или нет. Обычно для этого я задаю себе вопрос: «а что конкретно я тут тестирую??» и тогда решение дается проще. Если в вашем случае запросы к сервисам действительно имеют кучу параметров, то ваш текущий способ конечно же полностью оправдан.
Но все же, в случае регистрации/аутентификации через FB, параметров должно быть минимум. Я правда никогда не работал с API FB, и вероятно сильно ошибаюсь, но для меня эта ситуация кажется странной.
То что один юнит будет вызывать другой юнит с заданными параметрами и нужное количество раз как раз таки удобно тестировать с помощью моков. Ну и интеграционные тесты никто не отменяет, просто не нужно оценивать покрытие на основе интеграционных тестов.
Для защиты от таких атак нужно полностью изолировать пакеты и реализовать аутентификацию/авторизацию на уровне public API пакетов (фактически использовать пакеты в качестве микросервисов).
https://www.jetbrains.com/help/phpstorm/2016.2/working-with-phpstorm-features-from-command-line.html
https://www.jetbrains.com/help/ruby/2016.2/working-with-rubymine-features-from-command-line.html
etc
Для перехода по клику пользуюсь обработкой txmt протокола аналогично этому:
https://gist.github.com/gregd/1305906/c57a21e210aafd72102360cd3bdffb7ab195ed39
Ссылки с протоколом txmt в моем случае генерят сторонние библиотеки (ruby: better_errors, rails-footnotes)
Могу предположить, что возможности API соответствуют описанному механизму.
ИМХО, в таком случае уже появляется другая проблема — selenium для таких целей не очень подходит.
Фактически мы проверяем что сторонний API работает так как мы ожидаем. В этом конечно нет ничего плохого, но в данном случае лично я бы проверял именно ответы API, а не работу системы с данным API.
PS: Я просто пытаюсь рассуждать, не сочтите что я с вами спорю.
К сожалению, с mock'ами всегда имеется такая проблема=/ Мне вообще всегда довольно сложно дается ответ на вопрос использовать их или нет. Обычно для этого я задаю себе вопрос: «а что конкретно я тут тестирую??» и тогда решение дается проще. Если в вашем случае запросы к сервисам действительно имеют кучу параметров, то ваш текущий способ конечно же полностью оправдан.
Но все же, в случае регистрации/аутентификации через FB, параметров должно быть минимум. Я правда никогда не работал с API FB, и вероятно сильно ошибаюсь, но для меня эта ситуация кажется странной.