Нужна ли регистрация при выполнении TDD?

При выполнении цикла Red, Green & Refactor мы всегда должны писать минимальный код для прохождения теста. Именно так меня учили о TDD и как почти все книги описывают этот процесс.

Но как насчет регистрации?

Честно говоря, я редко использовал регистрацию в приложении, если не было чего-то действительно сложного, что происходило, однако я видел многочисленные посты, в которых говорится о важности правильной регистрации.
Таким образом, кроме регистрации исключений, я не мог оправдать реальную важность регистрации в надлежащем тестируемом приложении (модульные / интеграционные / приемочные тесты).

Итак, мои вопросы:

1. Нужно ли регистрироваться, если мы делаем TDD? провальный тест не покажет, что не так с приложением?
2. Должны ли мы добавить тест для процесса регистрации в каждом методе в каждом классе?
3. Например, если некоторые уровни журнала отключены в производственной среде, не приведет ли это к зависимости между тестами и средой?
4. Люди говорят о том, как журналы облегчают отладку, но одно из главных преимуществ TDD заключается в том, что я всегда знаю, что не так из-за неудачного теста.

Есть ли что-то, чего мне не хватает там?

1) Нужно ли регистрироваться, если мы делаем TDD? провальный тест не покажет, что не так с приложением?

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

2) Должны ли мы добавить тест для процесса регистрации в каждом методе в каждом классе?

Если сам регистратор протестирован, его не нужно будет повторно тестировать в каждом классе, подобно другим зависимостям.

3) Если некоторые уровни журнала отключены, например, в производственной среде, не приведет ли это к зависимости между тестами и средой?

Люди (и агрегаторы журналов) зависят от журналов, тесты не должны зависеть от них. Как правило, существует несколько уровней журнала, и некоторые используются в производстве, а некоторые дополнительные уровни используются при разработке, например:

«Уровень журнала Rails - это информация в производственном режиме и отладка при разработке и тестировании» - http://guides.rubyonrails.org/debugging_rails_applications.html

Другие приложения используют аналогичный подход.

4) Люди говорят о том, как журналы облегчают отладку, но одно из главных преимуществ TDD заключается в том, что я всегда знаю, что не так из-за неудачного теста.

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

Ведение журнала полезно для объяснения неисключительного поведения приложения:

Журналы событий регистрируют события, происходящие при выполнении системы, чтобы обеспечить контрольный журнал, который можно использовать для понимания деятельности системы и диагностики проблем. Они необходимы для понимания действий сложных систем, особенно в случае приложений с небольшим взаимодействием с пользователем (таких как серверные приложения) ...

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

результат вашей программы равен 0, в то время как мы ожидали, что он будет равен 1, почему?

Вам необходимо войти в систему, чтобы проверить настройки приложения, параметры и другие подробности времени выполнения, чтобы объяснить его (не исключительное) поведение.

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

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

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

Конечно, система, критичная к производительности, может / должна предоставлять ключевые показатели производительности для некоторой операционной панели, но «классическая» регистрация может обеспечить другой уровень детализации.

1. Если у вас нет 100% покрытия для тестирования, что, как правило, не так, вы не можете знать, что ваше программное обеспечение никогда не выйдет из строя (РЕДАКТИРОВАТЬ: и - как сказано в комментариях - даже если это произойдет, что-то независимое от вашего программного обеспечения может вызвать авария); это то же самое, что думать, что вы можете создать программное обеспечение, в котором нет абсолютно никаких ошибок (даже НАСА не может этого сделать). Поэтому, по крайней мере, вам нужно регистрировать возможные сбои в случае сбоя вашей программы, чтобы вы могли знать, почему.

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

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

4. Ошибка может быть очень неясной, и не всегда очевидно, что пошло не так, когда один тест TDD не прошел. Логи должны быть более точными. Например, если вы выполняете алгоритм сортировки, и весь тестовый пример терпит неудачу, у вас должны быть журналы для каждого отдельного теста алгоритма, которые помогут вам определить, где на самом деле лежит проблема.

Краткий ответ на ваш главный вопрос: как правило, ошибки в вашем коде НЕ будут обнаруживаться TDD. Некоторые могут, в идеале многие, но отсутствие неудачных тестов не означает отсутствие ошибок. Это очень важный принцип в тестировании программного обеспечения.

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

Регистрация и TDD решают различные проблемы.

Да, в общем случае вам нужно войти.

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

Но более важной частью ведения журнала является ремонтопригодность. Хорошо продуманная регистрация может ответить на следующие вопросы:

• Приложение все еще живо и работает? (Регистрируя сердцебиение каждые 1000 секунд.)
• Изменилась ли производительность приложения за последние 10 месяцев? (Записывая статистику производительности вариантов использования.)
• Изменилась ли загрузка приложения за последние 10 месяцев? (Записывая количество запросов на типы запросов.)
• Кто-нибудь из наших интерфейсов изменил свои характеристики производительности?
• Вызывает ли новый выпуск различные характеристики использования в отношении некоторых подсистем?
• Мы под атакой DoS ?
• Какие ошибки происходят?

Все это может быть достигнуто путем регистрации. И да, это должно быть спланировано, спроектировано и опробовано, желательно автоматическое.

Ведение журнала является функцией, которая заслуживает лечения, как и другие функции.

TL; DR: регистрация и TDD являются ортогональными. Наличие одного не имеет отношения к необходимости другого

Нужно ли регистрироваться, если мы делаем TDD? провальный тест не покажет, что не так с приложением?

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

Эти журналы предназначены для устранения неполадок, которые в основном связаны с точками интеграции. Это могут быть сетевые службы (база данных, мыло и т. Д.), Локальные ресурсы (диск, память и т. Д.), Неверные данные (данные клиента, неверные / поврежденные источники данных и т. Д.) И т. Д. Захват исключений, регистрация ошибок и даже информативная регистрация. (настройки, конфигурации и т. д.) могут помочь при устранении неполадок.

Должны ли мы добавить тест для процесса регистрации в каждом методе в каждом классе?

Добавьте тестирование везде, где вам нужно, чтобы проверить логирование. Если у вас есть специальные вызовы для выхода из системы, их следует проверить. Хотя, если вы реализуете ведение журналов и тестирование журналов с использованием Аспектно-ориентированного программирования или метапрограммирования, это может снизить нагрузку на тестирование.

Например, если некоторые уровни журнала отключены в производственной среде, не приведет ли это к зависимости между тестами и средой?

Если вы пишете свой код с использованием IoC и используете макеты, вы должны быть в состоянии эффективно протестировать все свои журналы, не полагаясь на определенные настройки среды.

TDD обычно помогает уменьшить количество ошибок в кодировании. Это намного меньше помогает с ошибками в спецификации или просто с недопониманием того, как все работает.

«О? Вы можете получить сообщение с данными, прежде чем получите подтверждение, что вход в систему прошел успешно? Я никогда не знал этого, ну, он не справится с этим!» ... Подобные вещи. Регистрация очень полезна для того, чтобы сообщать вам, что пыталось сделать программное обеспечение, чтобы вы могли определить, что вы сделали неправильно.

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

Принимая во внимание, что, когда я делаю TDD (или, может быть, тестирую) всякий раз, я добавляю намного меньше записей журнала. Это, в свою очередь, означает меньше LOC и может (не всегда) влиять на производительность.

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

Примером могут быть методы компонента EJB-сервиса, которые присутствуют в общедоступном интерфейсе. Другим может быть случай, когда функция выполняет сложные вычисления. Это может очень помочь иметь цифры, входящие в метод (например, вы можете написать модульный тест, чтобы вернуться к общей теме под рукой).