Test Infected

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

Тест в первую очередь должен проверять максимальное количество ситуаций где метод может упасть. Если вы написали допустим 10 тестов на метод, покрыли скажем 50% кода — как вы можете быть уверены в том, что остальные 50% не упадут. Будем исходить из идеала что каждый тест проверяет идеально свой участок кода.

Вы и с тестами не можете быть уверены, что остальные 50% не упадут.

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

Мне кажется, что тесты — это крайне полезный инструмент, который позволяет разгрузить голову программиста, облегчить рефакторинг, совместную разработку и автоматизировать процесс отладки, но не самоцель. Писать тесты ради тестов кажется неправильным. Мне думается, что тесты стоит писать именно исходя из их назначения. Что тесты стоит писать только тогда, когда их стоит писать) Ведь если писать слишком много тестов, то появляется большая вероятность, что то, что нужно, как раз останется непротестированным. Мне поэтому TDD в чистом виде кажется хуже, чем какой-нибудь прагматичный компромиссный подход, когда тесты не пишутся для тривиальных мест кода или тогда, когда их написание требует несоразмерно больших усилий. Тесты для сложных мест + тесты при исправлении багов — такой подход уже дает процентов 90 всех плюсов, которые можно получить от тестирования, при небольших усилиях.

Я вот перечитал 2 раза, а понять не могу: либо вы неправильно свои 90% посчитали, либо я дурак. Если тестами покрыто 100% кода, то это может значит только то, что тестами покрыто 100% кода. То есть весь код. Целиком. Если хоть где-то хоть что-то вдруг станет работать не так — я узнаю сразу.

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

Я считал «по старинке»: строка выполнилась во время тестирования — строка протестирована. Ну да, это неправильно, а как правильно-то посчитаешь. Есть хитрые попытки учитывать логику в coverage (например, что-то такое в coverage.py имеется), но думаю, что обычно считают так, по-простому (поправьте, если нет, кругозор в этой области не велик). В coverage попадал только мой код, без библиотечного, т.к. библиотечного много, он сам по себе оттестирован, он универсален (имеет функционал и логические ветки внутри, которые я не использую и не собираюсь использовать) и часто может быть на другом языке написан.

Такое условие не может ничего гарантировать кроме того, что строка при каких-то условиях (в каком-то состоянии системы и окружения) выполнится без ошибки. Это не может гарантировать того, что код без ошибок. И 100% покрытие этой гарантии не даст. Гарантию даст только математическое доказательство правильности алгоритмов (всех!) и полное знание состояния окружения, но такая гарантия никому не нужна, тесты пишут не ради гарантий, а ради удобства рефакторинга. Эти 100% — точно такая же цифра, как 90%, и как 50%: принципиально других преимуществ 100% по сравнению с 90% или 50% не дает.

Оно даст только гарантию того, что при каком-то состоянии системы и окружения код выполняется без ошибок (не «упадет») и при этом удовлетворяются некоторые условия (совсем не обязательно связанные с выполненными строками). Покрытие само по себе не гарантирует ни множество состояний системы/окружения, ни того, что удовлетворяются те условия, которые важны для выполненных строк (из которых эти проценты формируются).

Оно, к тому же, в моем случае не проверяет все варианты работы стороннего кода (и «стыковку» стороннего кода с нашим). Вот ниже пример с делением. По сути, деление можно рассматривать как вызов библиотечной функции. Некоторая комбинация входных параметров — ошибочна. Код операции деления не попадает в coverage, т.к. он зашит в микропроцессор, и мы не видим, что ветка, связанная с обработкой 0 в знаменателе, не оттестирована.

Еще пример: тестируем веб-приложение. Пишем бота, который обходит все страницы подряд и постит формы с данными. Проверяет, что в ответ приходит статус 200. Имеем от этого test coverage, близкий к 100%. Это полезные тесты, их цель — смотреть, не поломалось ли чего глобально. Но они не очень помогут в отладке и рефакторинге какого-то конкретного места, для этого полезнее написать юнит-тест, которые будет проверять API на программном уровне, а не на уровне интерфейса пользователя. Юнит-тест (вероятно, более важный и полезный в конкретной ситуации) вполне может не быть написан, если код учтен в coverage, а программист, привыкший следить за code coverage и принимать на его основе решения, видит это.

Как можно покрыть тестами 90% кода так, чтобы они мало что тестировали?

Я оказался на это способен) Рецепт примерно такой: пишем тесты, максимально увеличивающие code coverage. Это стремление приводит к тому, что проверять условия становится трудно, и трудно понять, какие именно условия стоит проверять. Количество тех, которые имеется возможность проверить, растет гораздо быстрее количества тех, которые есть смысл проверять. В итоге многие условия остаются непроверенными, теряются среди других, работа некоторых кусков кода проверяется однообразно по многу раз, работа других не проверяет совсем.

Не стоит, короче говоря, интеграционными тестами заменять юнит-тесты.

Тут можно бы подумать, что если писать хорошие тесты, то при code coverage 100% все будет здорово. И действительно, это так. Другое дело что все будет здорово и задолго до того, как покрытие будет 100%, если писать хорошие тесты. Нам тесты нужны ведь не только и не столько для самоуспокоения, а требуются они для практических целей — для удобства проведения рефакторинга, и это удобство будет обеспечено гораздо раньше.