Должны ли модульные тесты использовать протоколирование?

В этой теме, по-видимому, есть две тенденции:

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

Должны ли модульные тесты регистрировать то, что они делают? Помогут ли эти дополнительные сведения в отчетах unit test? Или должны ли модульные тесты молчать до тех пор, пока они не сбой?

Мой вопрос нацелен на модульные тесты Java, но также может быть интересен ввод от программистов на других языках.

Ответ 1

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

Если вы запускаете консоль, цветной вывод - это плюс, я думаю.

Ответ 2

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

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

Я согласен с ним в этом.

Кроме того, у вас все еще может быть ваш обычный журнал. У вас это все равно в классах, которые вы тестируете (или должны иметь). Когда тест выходит из строя, вы можете увидеть что-то в журнале, что поможет вам быстрее его отладить. Я не вижу, как это может быть отрицательным моментом.

Ответ 3

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

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

Ответ 4

Обычно, когда вы пишете тесты, одна из первых вещей, которые вы узнаете, заключается в том, что модульные тесты не должны подключаться ни к чему - база данных, файловая система, интернет. A unit test должен быстро разгораться и работать независимо от среды, в которой вы работаете. Если она подключается к чему-то, это тест интеграции. Я бы сказал, что использование структуры протоколирования, которая может значительно снизить скорость модульных тестов, - это то, что противоречит философии модульного тестирования. Вся идея заключается в том, что вы можете запускать тысячи, десятки тысяч тестов по каждой своей прихоти. Идеальным было бы, чтобы ваш набор unit test подключался к вашей кнопке сохранения (на самом деле не правдоподобно, но вы получаете мой дрейф).

Ответ 5

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