Является ли 100% покрытие кода несбыточной мечтой?

Можно ли ожидать 100% покрытия кода в тяжелых веб-приложениях jquery / backbonejs? Разумно ли проваливать спринт из-за 100% покрытия, которое не выполняется, когда фактическое покрытие кода колеблется около 92% -95% в javascript / jquery?

Это так же реалистично, как и нереально.

Реалистичный
Если у вас есть автоматическое тестирование, которое, как было показано, охватывает всю кодовую базу, тогда настаивать на 100% охвате разумно.
Это также зависит от того, насколько критичен проект. Чем критичнее, тем разумнее ожидать / требовать полного покрытия кода.
Это легче сделать для небольших и средних проектов.

Нереально
Вы начинаете с охватом 0% ...
Проект чудовищный, со многими, многими путями ошибок, которые трудно воссоздать или вызвать.
Руководство не желает совершать / инвестировать, чтобы обеспечить покрытие.

Я работал с целым рядом проектов, начиная от без покрытия до приличных. Никогда не проект со 100%, но были случаи, когда я хотел, чтобы у нас было ближе к 100% охват.
В конечном итоге вопрос заключается в том, соответствует ли существующее покрытие достаточному количеству необходимых случаев, чтобы команда могла чувствовать себя комфортно при доставке продукта.

Мы не знаем влияния неудачи на ваш проект, поэтому мы не можем сказать, достаточно ли 92% или 95%, или если эти 100% действительно необходимы. Или в этом отношении, 100% полностью проверяет все, что вы ожидаете.

Кто тестирует тесты?

Это очень наивно в лучшем случае и нереально даже в теоретическом смысле и непрактично в деловом смысле.

• Это нереально с кодом, который имеет высокую цикломатическую сложность. Слишком много переменных, чтобы охватить каждую комбинацию.
• Это нереально с кодом, который сильно параллелен. Код не является детерминированным, поэтому вы не можете охватить все условия, которые могут произойти, потому что поведение будет меняться при каждом запуске теста.
• В деловом смысле это нереально, только на самом деле платит дивиденды на написание тестов для кода, который является критическим путевым кодом, то есть кода, который важен, и кода, который может часто изменяться.

Тестирование каждой строки кода не является хорошей целью

Написание тестов очень дорого, это код, который должен быть написан и протестирован сам, это код, который должен быть документирован в том, что он на самом деле пытается протестировать, это код, который должен сопровождаться изменениями бизнес-логики и тесты не пройдены, потому что они устарели. Поддерживать автоматизированные тесты и документацию о них может быть дороже, чем поддерживать код иногда.

Это не означает, что модульное тестирование и интеграционные тесты бесполезны, но только там, где они имеют смысл, и вне отраслей, которые могут убивать людей, не имеет смысла пытаться протестировать каждую строку кода в базе кода. Помимо этих критических убийств многие люди быстро кодируют базы, невозможно рассчитать положительный возврат инвестиций, который повлечет за собой 100% покрытие кода.

Проблема остановки:

В теории вычислимости проблема остановки - это проблема определения, исходя из описания произвольной компьютерной программы и входных данных, будет ли программа завершена или будет работать вечно.

Алан Тьюринг доказал в 1936 году, что общего алгоритма для решения проблемы остановки для всех возможных пар ввода программы не может быть. Ключевой частью доказательства было математическое определение компьютера и программы, которые стали называться машиной Тьюринга; проблема остановки неразрешима над машинами Тьюринга. Это один из первых примеров решения проблемы.

Поскольку вы даже не можете доказать, что что-то работает на 100%, зачем делать это своей целью?

Просто и понятно, в большинстве случаев это не имеет никакого делового смысла.

В большинстве случаев 100% покрытие кода означает, что вы немного «обманули»:

• Сложные, часто меняющиеся части системы (например, графический интерфейс) были перемещены в декларативные шаблоны или другие DSL.
• Весь код, касающийся внешних систем, был изолирован или обработан библиотеками.
• То же самое касается любой другой зависимости, особенно требующей побочных эффектов.

В основном, труднодоступные для тестирования детали были перенесены в области, где они не обязательно считаются «кодом». Это не всегда реалистично, но учтите, что независимо от того, как помочь вам в тестировании, все эти методы облегчают работу с вашим кодом.

Впечатляющий, реальный пример 100% охвата веток см. В разделе Как тестируется SQLite .

Я понимаю, что ваш вопрос конкретно касается javascript, который представляет собой совершенно другой тип программного продукта, но я хочу донести до понимания, что можно сделать с достаточной мотивацией.

100% покрытие кода для модульных тестов для всех частей конкретного приложения - несбыточная мечта, даже с новыми проектами. Хотелось бы, чтобы это было так, но иногда вы просто не можете охватить кусок кода, независимо от того, как сильно вы пытаетесь абстрагироваться от внешних зависимостей. Например, предположим, что ваш код должен вызывать веб-сервис. Вы можете скрыть вызовы веб-службы за интерфейсом, чтобы смоделировать эту часть и проверить бизнес-логику до и после веб-службы. Но фактическая часть, которая должна вызвать веб-сервис, не может быть проверена модулем (в любом случае, очень хорошо). Другой пример, если вам нужно подключиться к TCP-серверу. Вы можете скрыть код, который подключается к TCP-серверу за интерфейсом. Но код, который физически подключается к серверу TCP, не может быть проверен модулем, потому что, если он по какой-либо причине не работает, это может привести к сбою модульного теста. И модульные тесты должны всегда проходить, независимо от того, когда они вызываются.

Хорошее практическое правило - вся ваша бизнес-логика должна иметь 100% покрытие кода. Но части, которые должны вызывать внешние компоненты, должны иметь максимально приближенное к 100% покрытие кода. Если ты не сможешь достичь, я бы не стал слишком потеть.

Гораздо важнее, правильны ли тесты? Они точно отражают ваш бизнес и требования? Наличие покрытия кода только наличием покрытия кода ничего не значит, если все, что вы делаете, это тестирование неправильно или тестирование неверного кода. При этом, если ваши тесты хороши, то охват 92-95% является выдающимся.

Я бы сказал, что если код не разработан с конкретной целью обеспечения 100% покрытия тестами, 100% может оказаться недостижимым. Одна из причин может заключаться в том, что если вы защищаете код - что вам следует - у вас должен иногда быть код, который обрабатывает ситуации, которые, как вы уверены, не должны происходить или не могут происходить, учитывая ваши знания о системе. Покрыть такой код тестами было бы очень сложно по определению. Отсутствие такого кода может быть опасным - что, если вы ошибаетесь, и такая ситуация случается один раз из 256? Что если в несвязанном месте произошли изменения, которые делают невозможное невозможным? И т. Д. Таким образом, 100% может быть довольно трудно достичь "естественными" средствами - например, если у вас есть код, который выделяет память, и у вас есть код, который проверяет, не сработал ли он, если вы не макете менеджер памяти (что может быть непросто) и написать тест, который возвращает «недостаточно памяти», охватывая этот код может быть сложно. Для приложения JS это может быть защитное кодирование вокруг возможных причуд DOM в разных браузерах, возможных сбоев внешних служб и т. Д.

Поэтому я бы сказал, что нужно стремиться к тому, чтобы быть как можно ближе к 100%, и иметь хорошую причину для дельты, но я бы не увидел, что не получится точно 100% как неизбежный провал. 95% может быть хорошо для большого проекта, в зависимости от того, что 5%.

Если вы начинаете с нового проекта и строго используете методику тестирования вначале, то вполне разумно иметь 100% покрытие кода в том смысле, что весь ваш код будет вызываться в какой-то момент, когда ваши тесты был казнен. Тем не менее, возможно, вы не провели явного тестирования каждого отдельного метода или алгоритма напрямую из-за видимости метода, а в некоторых случаях вы могли не тестировать некоторые методы даже косвенно.

Получение 100% тестируемого кода является потенциально дорогостоящим упражнением, особенно если вы не разработали свою систему, чтобы позволить вам достичь этой цели, и если вы сосредоточили свои усилия на разработке на тестируемости, вы, вероятно, не уделяете достаточного внимания для разработки вашего приложения в соответствии с его конкретными требованиями, особенно если проект большой. Извините, но вы просто не можете получить это в обоих направлениях без компрометации чего-либо.

Если вы вводите тесты в существующий проект, в котором тестирование не проводилось или не было включено ранее, то невозможно получить 100% покрытие кода, если затраты на его выполнение не перевешивают усилия. Лучшее, на что вы можете надеяться, это обеспечить тестовое покрытие для критических разделов кода, которые называются больше всего.

Разумно ли проваливать спринт из-за 100% покрытия, которое не выполняется, когда фактическое покрытие кода колеблется около 92% -95% в javascript / jquery?

В большинстве случаев я бы сказал, что если вы не достигли своих целей, вы должны рассматривать свой спринт как «неудачный». На самом деле, я предпочитаю не думать о спринтах как о неудачных в таких случаях, потому что вам нужно уметь учиться на спринтах, которые не соответствуют ожиданиям, чтобы правильно спланировать планирование в следующий раз, когда вы определите спринт. Несмотря на это, я не думаю, что разумно считать покрытие кода фактором относительного успеха спринта. Ваша цель должна состоять в том, чтобы сделать все, чтобы все работало так, как указано, и если вы программируете тестирование в первую очередь, тогда вы должны быть уверены, что ваши тесты будут поддерживать эту цель. Любое дополнительное тестирование, которое, по вашему мнению, вам может понадобиться, эффективно покрывает сахар, и, следовательно, это дополнительные расходы, которые могут удержать вас в удовлетворительном завершении спринта.

Я не делаю это как само собой разумеющееся, но я сделал это на двух крупных проектах. Если у вас в любом случае есть фреймворк для модульных тестов, то это не сложно, но в целом это приводит к большому количеству тестов.

Есть ли какое-то конкретное препятствие, с которым вы сталкиваетесь, мешающее вам попасть в эти последние несколько строк? Если нет, если получение от 95% до 100% покрытия является простым, так что вы можете пойти и сделать это. Так как вы здесь спрашивать, я буду считать , что это что - то. Что это такое?

92% в порядке. Я чувствую, что настоящие вопросы:

• Является ли 92% «новой» нормой сейчас? Если у следующего спринта будет 88% тестов, это будет хорошо? Это часто начало заброшенных наборов тестов.

• Насколько важно, чтобы программное обеспечение работало и не имело ошибок. У вас есть тесты по этим причинам, а не "ради тестирования"

• Есть ли план вернуться и заполнить пропущенные тесты?

• Почему ты тестируешь? Кажется, что фокус -% покрытой линии, а не функциональность

Мартин Фаулер пишет в своем блоге :I would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.

Тем не менее, существуют даже стандарты, которые предусматривают 100% охват на уровне подразделений. Например, это одно из требований стандартов европейского космического полета (ECSS, Европейское сотрудничество по стандартизации космоса). Связанный здесь документ рассказывает интересную историю проекта, целью которого было достичь 100% покрытия тестами в уже готовом программном обеспечении. Он основан на беседах с вовлеченными инженерами, которые разработали модульные тесты.

Некоторые из уроков:

• 100% покрытие необычно, но достижимо
• Иногда необходимо 100% покрытие
• 100% покрытие приносит новые риски
• Не оптимизировать для 100% -метрических
• Разработать правильную стратегию для максимального охвата
• 100% покрытие не является достаточным условием для хорошего качества

Возможно, вопрос о том, является ли это возможным и разумным, не самый полезный вопрос. Вероятно, самый практичный ответ - принятый. Я проанализирую это на более философском уровне.

100% охват был бы идеальным, но в идеале он не был бы необходим или его было бы намного легче достичь. Я предпочитаю думать о том, является ли это естественным и человеческим, чем осуществимым или разумным.

Правильное программирование практически невозможно с современными инструментами. Очень сложно написать абсолютно правильный код, в котором нет ошибок. Это просто не естественно. Итак, без другого очевидного варианта мы обратимся к таким методам, как TDD и отслеживание покрытия кода. Но пока конечный результат все еще неестественный процесс, вам будет трудно заставить людей делать это последовательно и счастливо.

Достижение 100% покрытия кода - противоестественный акт. Для большинства людей принуждение их к достижению этого было бы формой пытки.

Нам нужны процессы, инструменты, языки и код, которые соответствуют нашим естественным ментальным моделям. Если мы этого не сделаем, мы не сможем проверить качество продукта.

Просто посмотрите на все программное обеспечение сегодня. Большинство из них портятся довольно регулярно. Мы не хотим в это верить. Мы хотим верить, что наши технологии волшебны и делают нас счастливыми. И поэтому мы предпочитаем игнорировать, оправдывать и забывать большую часть времени, когда наши технологии портятся. Но если мы будем честно оценивать ситуацию, то большая часть программного обеспечения сегодня довольно дрянная.

Вот пара попыток сделать кодирование более естественным:

https://github.com/jcoplien/trygve

https://github.com/still-dreaming-1/PurposefulPhp

Последнее крайне неполно и экспериментально. На самом деле это проект, который я начал, но я верю, что это был бы огромный шаг вперед для мастерства программирования, если бы я когда-нибудь смог найти время для его завершения. По сути, это идея о том, что если контракты выражают единственные аспекты поведения классов, которые нас интересуют, и мы уже выражаем контракты как код, то почему бы не иметь определения классов и методов вместе с контрактами. Таким образом, контракты были бы кодом, и нам не нужно было бы реализовывать все методы. Позвольте библиотеке выяснить, как выполнить контракты для нас.

Достижение 100% нового кода должно быть очень достижимым, и если вы практикуете TDD, вы, вероятно, достигнете этого по умолчанию, поскольку вы очень намеренно пишете тесты для каждой строки производственного кода.

В существующем унаследованном коде, который был написан без модульных тестов, это может быть затруднительно, поскольку часто унаследованный код не был написан с учетом модульного тестирования и может потребовать большого количества рефакторинга. Такой уровень рефакторинга часто непрактичен, учитывая реалии риска и графика, поэтому вы делаете компромиссы.

В моей команде я указываю 100% покрытие кода, и если мы увидим меньше, чем в обзоре кода, технический владелец компонента обсудит, почему 100% не было достигнуто с разработчиком, и должен согласиться с доводами разработчика. Часто, если есть проблема с достижением 100%, разработчик поговорит с техническим владельцем перед проверкой кода. Мы обнаружили, что, как только вы овладеете привычкой и изучите методы для решения нескольких распространенных проблем с добавлением тестов в унаследованный код, которые регулярно достигают 100%, это не так сложно, как вы изначально думали.

Книга Майкла Фезера « Эффективная работа с устаревшим кодом » была для нас неоценима, поскольку мы разработали стратегии добавления тестов в наш устаревший код.

Нет, это невозможно и никогда не будет. Если бы это было возможно, вся математика впала бы в финитизм. Например, как бы вы протестировали функцию, которая взяла два 64-битных целых числа и умножила их? Это всегда было моей проблемой с тестированием, а не с проверкой правильности программы. Для чего угодно, кроме самых тривиальных программ, тестирование в основном бесполезно, поскольку охватывает лишь небольшое количество случаев. Это все равно что проверить 1000 номеров и сказать, что вы доказали гипотезу Гольдбаха.