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

41

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

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

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

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

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

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

Songo
источник
5
Я думаю, что регистрация - это особый случай для многих правил. Класс / функция должны выполнять одно и только одно ... кроме ведения журнала. Функции предпочтительно должны быть чистыми, за исключением регистрации. Так далее и тому подобное. Ведение журнала нарушает правила.
Фоши
1
Разве регистрация не ортогональна какой-либо используемой методологии разработки ПО? Поэтому, возможно, вам следует просто сузить его и спросить: нужны ли нам тестовые случаи для регистрации при выполнении TDD?
Hyde

Ответы:

50

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

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

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

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

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

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

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

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

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

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

FMJaguar
источник
26
Даже идеально выполненный, строго выполненный TDD не предотвратит производственных проблем с производительностью, системным взаимодействием, сторонним взаимодействием. Проблемы параллелизма также очень трудно полностью охватить тестированием. 100% тестовое покрытие «только» означает, что 100% вашего кода было выполнено, что не является правильным во всех состояниях или средах.
Хольстебро
34

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

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

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

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

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

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

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

комар
источник
5
+1 за "логирование больше ориентировано на поддержку". Действительно ударил гвоздь по голове.
Тибос
1
+1 за «неординарное поведение», а также за «ведение журнала больше ориентировано на поддержку». Но не могли бы вы отредактировать свой ответ, чтобы перечислить источник абзаца, который вы цитируете?
Журнал
@log цитата источника указывается ссылкой в ​​самом первом слове здесь, «Logging» - если вы нажмете на нее, вы попадете в статью в Википедии: en.wikipedia.org/wiki/Logfile
gnat
16

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

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

Johannes
источник
2
Также не забывайте о ведении журнала для целей аудита. Или биллинг. Или различные виды статистики. Или регистрация событий для сопоставления с другими видами статистики других систем.
PlasmaHH
Разве это не то, что вы бы сделали без регистрации? Или вы просто имеете в виду, что можете непрерывно регистрировать результаты профилирования?
Берги
@Bergi: полностью зависит от того, как работает ваше приложение. Если это, например, веб-приложение, то регистрация времени обслуживания каждого запроса, а затем попытка кластеризовать эти события для «плохих исполнителей» также может работать.
PlasmaHH
@Bergi-профилирование происходит в процессе разработки, но следует помнить о влиянии на работающие системы, использование дисков может стать медленным, загрузка ЦП может быть более высокой, службы могут не отвечать вовремя, параллельные потоки могут столкнуться с проблемами блокировки ...
Йоханнес
Аудит @PlasmaHH является частью основных требований и должен охватываться тестами. В большинстве случаев я не запускаю его по «обычным» маршрутам регистрации. Нормальная регистрация может завершиться неудачей, а аудит - нет. "различную статистику" я собрал под спектакль;)
Йоханнес
8
  1. Если у вас нет 100% покрытия для тестирования, что, как правило, не так, вы не можете знать, что ваше программное обеспечение никогда не выйдет из строя (РЕДАКТИРОВАТЬ: и - как сказано в комментариях - даже если это произойдет, что-то независимое от вашего программного обеспечения может вызвать авария); это то же самое, что думать, что вы можете создать программное обеспечение, в котором нет абсолютно никаких ошибок (даже НАСА не может этого сделать). Поэтому, по крайней мере, вам нужно регистрировать возможные сбои в случае сбоя вашей программы, чтобы вы могли знать, почему.

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

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

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

Пьер Арло
источник
4
Даже если у вас есть 100% покрытие, есть ли оно у вас во всех возможных случаях? Что если сетевое соединение с вашей базой данных оборвется? Ваши тесты скажут вам это?
Захари К
Вы никогда не узнаете, что ваше программное обеспечение никогда не рухнет, даже если у вас 100% охват. 100% покрытие, хотя и желательно, дает гораздо меньше информации о правильности, чем может показаться.
Андрес Ф.
Да, вы тоже правы в этом. Дело в том, что невозможность сбоя невозможна. Я отредактирую
Пьер Арло,
1
Редактирование все еще неверно. Даже если у вас 100% тестовое покрытие, в вашем коде может быть ошибка (не нужно обвинять внешние причины). Тесты НЕ подразумевают работу вашего кода; единственное, что они подразумевают с какой-либо определенностью, - это то, что вы не смогли написать тест, который обнаружил бы ошибку :) Охват тестами является важной метрикой, но она не связана напрямую с отсутствием ошибок.
Андрес Ф.
4
Это тривиально доказать, что "100% тестирование пройдено! = Без ошибок". Контрпример: add(x, y) = 2(всегда возвращает 2). Следующий тест проходит и обеспечивает полный охват: assert(2 == add(1,1)). 100% тестовое покрытие для глючной функции :)
Andres F.
8

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

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

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

Андрес Ф.
источник
5

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

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

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

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

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

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

Йенс Шаудер
источник
4

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

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

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

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

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

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

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

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

dietbuddha
источник
3

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

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

Johnb
источник
2

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

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

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

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

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