Винду соседке ставить, это не работа, это статья.
*плохая шутка.
Следом за принятием закона об обязательной регистрации ресурсов будет очень логичным шагом ввести белый список интернет ресурсов на основе списка зарегистрированных. В этом случае, можно будет считать, что интернета нет.
Есть вероятность, что антитеррористические законы коснутся фрилансеров в части перевода в Россию честно заработанных средств. Уж очень похоже на схему финансирования террористов.
*мысли в слух
Вы натолкнули на интересную мысль. Если убить в России интернет индустрию, то на рынке окажется огромное колличество специалистов, которым некуда будет в России податься, кроме как работать на государство.
Телефоны Nokia будут отличаться от большинства других Android-смартфонов, в том числе в них не будет некоторых функций от Google и доступа к Google Play. В телефоне будут предустановлены сервисы от Nokia и Microsoft, такие как карты Here и музыкальный сервис MixRadio, а также магазин приложений Nokia.
Для посещения i2p страничек рекомендуется использовать две виртуалки. На одной два сетевых интерфейса. Один в интернет, другой — на вторую виртуалку. На неё ставится ip2 прокси, который доступен для второй виртуалки. На второй виртуалке — браузер. И там в принципе нет никакого интернета, кроме i2p. Даже днсов нет.
Я предположил, что любая ошибка, в юнит тесте приводит к ложноположительному результату в случае наличия любой ошибки в коде. В случае хороших тестов, это может быть неверно, и может получиться результат гораздо лучше. В случае плохих — когда часть случаев не покрыта тестами, — наоборот.
Кстати… очень интересно посмотреть зависимость этих чисел от длины кусочков кода. Становится понятно подсознательное желание побить код на как можно более мелкие независимо тестируемые кусочки…
Для тестов тоже нужны тесты ;-) Ибо наличие тестов не гарантирует корректности…
Если предположить, что в каждой строчке кода содержится ошибка с вероятностью 0,001, то в 100 строках кода хотябы одна ошибка будет с вероятностью 0,0952
Предположим, что мы написали 100 строк юнит тестов. Юнит тест содержит ошибку с той же вероятностью. Вероятность ложно-положительного юнит-теста (читай, что ошибка попадет в продакшен) в этом случае будет 0,00906304 (в 10 раз меньше).
Встраивание в инструменты рефакторинга это следующий уровень постижения дзэн… Но, не написав тестов на то, что встраивание в инструменты рефакторинга работает правильно, мы не можем быть уверены, что инструменты рефакторинга после встраивания работают правильно. Следовательно, и в том, что их использование не нарушает корректности программы.
В итоге тесты всё равно нужны, только не на саму программу, а на «встраивание в инструменты рефакторинга» и это замкнутый круг, разорвать который можно лобо тестированием, либо автоматическим доказательством корректности кода, что ещё более трудоемко…
Вы вступили на скользкий путь холивара на тему «что лучше, юнит тесты или функциональные тесты».
Для себя я сам не решил, что лучше, и использую и то, и то, в зависимости от ситуации, но в своем комментарии я не говорил про какие-то конкретные виды тестов. Я говорил про необходимость тестов вообще. Потому не понимаю, почему вы, называя мое утверждение чушью, сами — фактически утверждаете то же самое.
На соглашения обычно пишут один тест (или генератор тестов), который проверяет их выполнение во всем проекте. После этого необходимость написания дополнительных тестов на выполнение соглашения отпадает. Только вот такие тесты иногда оказывают влияние на архитектуру.
Пример решения вышеупомянутой проблемы:
Вводится соглашение, что каждый класс, который допускает создание через контейнер — помечается аттрибутом. Пишется тест, который проверяет, что все классы, помеченные аттрибутом имеют публичный конструктор. Дополнительный бонус — разработчик знает, что если класс помечен аттрибутом, то выполнять рефакторинг «Introduce factory method» — возможно не стоит.
В завасимости от языка и конкретной среды разработки, набор гарантираванно безопасных рефакторингов разнится, и для таких языков как Java или C# далеко не полон, и не достаточен для серьезного рефакторинга. Это вызвано тем, что инструменты рефакторинга опраются на статически выводимую на основании анализа кода информацию, а есть ещё рантайм…
Например, в сишарпе «безопасным» рефакторингом «Introduce factory method» можно легко сломать всю систему, т.к. инструмент рефакторинга не знает, что класс может инстанциироваться через DI фреймворк, которому нужен открытый конструктор (а рефакторинг делает его приватным).
Поэтому, безопасные автоматические рефакторинги не отменяют необходимости в тестах, так как их «безопасность» во многих случаях — условна.
Фаулер писал, что наличие тестов — это необходимое условие для проведения рефакторинга. А рефакторинг, это единственный способ улучшения архитектуры уже написанного приложения в случае, если в этом появится необходимость.
Даже если у нас не супер хорошо спроектированный код, который покрыт тестами, то, при возникновении необходимости, мы сможем его отрефакторить. А вот если тестов нет — не сможем, какой хороший код бы ни был.
Отсюда простое следствие, если без изменений в архитектуре нельзя покрыть код тестами, значит это изменение в архитектуре сделать нужно, потому что если не покрыть код тестами… см. первый абзац…
*плохая шутка.
Следом за принятием закона об обязательной регистрации ресурсов будет очень логичным шагом ввести белый список интернет ресурсов на основе списка зарегистрированных. В этом случае, можно будет считать, что интернета нет.
Есть вероятность, что антитеррористические законы коснутся фрилансеров в части перевода в Россию честно заработанных средств. Уж очень похоже на схему финансирования террористов.
*мысли в слух
И кому он такой нужен?..
Если мои данные не устарели, то оно всё равно не работает одновременно с пробросом PCI устройств.
Согласен, грубое. Но для приведенной грубой модели — вполне допустимое :-)
Я учел. Это было сказано про ошибку в юнит тесте без учета его результата:
С учетом результата у меня получилось вот это:
Я предположил, что любая ошибка, в юнит тесте приводит к ложноположительному результату в случае наличия любой ошибки в коде. В случае хороших тестов, это может быть неверно, и может получиться результат гораздо лучше. В случае плохих — когда часть случаев не покрыта тестами, — наоборот.
Если предположить, что в каждой строчке кода содержится ошибка с вероятностью 0,001, то в 100 строках кода хотябы одна ошибка будет с вероятностью 0,0952
Предположим, что мы написали 100 строк юнит тестов. Юнит тест содержит ошибку с той же вероятностью. Вероятность ложно-положительного юнит-теста (читай, что ошибка попадет в продакшен) в этом случае будет 0,00906304 (в 10 раз меньше).
Итого:
100 строк кода — 0,0952 вероятность ошибки в продакшене
100 строк кода + 100 строк тестов = 0,00906304 вероятность ошибки в продакшене
100 строк кода + 100 строк кода = 0,181 вероятность ошибки в продакшене
Не бейте тапками, ибо я предположил, что ошибки не всязаны между собой.
http://habrahabr.ru/post/203398/
В итоге тесты всё равно нужны, только не на саму программу, а на «встраивание в инструменты рефакторинга» и это замкнутый круг, разорвать который можно лобо тестированием, либо автоматическим доказательством корректности кода, что ещё более трудоемко…
Для себя я сам не решил, что лучше, и использую и то, и то, в зависимости от ситуации, но в своем комментарии я не говорил про какие-то конкретные виды тестов. Я говорил про необходимость тестов вообще. Потому не понимаю, почему вы, называя мое утверждение чушью, сами — фактически утверждаете то же самое.
На соглашения обычно пишут один тест (или генератор тестов), который проверяет их выполнение во всем проекте. После этого необходимость написания дополнительных тестов на выполнение соглашения отпадает. Только вот такие тесты иногда оказывают влияние на архитектуру.
Пример решения вышеупомянутой проблемы:
Вводится соглашение, что каждый класс, который допускает создание через контейнер — помечается аттрибутом. Пишется тест, который проверяет, что все классы, помеченные аттрибутом имеют публичный конструктор. Дополнительный бонус — разработчик знает, что если класс помечен аттрибутом, то выполнять рефакторинг «Introduce factory method» — возможно не стоит.
Например, в сишарпе «безопасным» рефакторингом «Introduce factory method» можно легко сломать всю систему, т.к. инструмент рефакторинга не знает, что класс может инстанциироваться через DI фреймворк, которому нужен открытый конструктор (а рефакторинг делает его приватным).
Поэтому, безопасные автоматические рефакторинги не отменяют необходимости в тестах, так как их «безопасность» во многих случаях — условна.
Даже если у нас не супер хорошо спроектированный код, который покрыт тестами, то, при возникновении необходимости, мы сможем его отрефакторить. А вот если тестов нет — не сможем, какой хороший код бы ни был.
Отсюда простое следствие, если без изменений в архитектуре нельзя покрыть код тестами, значит это изменение в архитектуре сделать нужно, потому что если не покрыть код тестами… см. первый абзац…