Должны ли вы отображать, что происходит в модульном тесте во время его работы? - PullRequest
4 голосов
/ 06 октября 2008

Поскольку я кодирую свои модульные тесты, я обнаруживаю, что вставляю следующие строки:

Console.WriteLine("Starting InteropApplication, with runInBackground set to true...");
try
{
    InteropApplication application = new InteropApplication(true);
    application.Start();
    Console.WriteLine("Application started correctly");
}
catch(Exception e)
{
    Assert.Fail(string.Format("InteropApplication failed to start: {0}", e.ToString()));
}

//test code continues ...

Все мои тесты - одно и то же. Они отображают информацию о том, почему они потерпели неудачу, или они отображают информацию о том, что они делают. У меня не было никаких формальных методов того, как должны быть закодированы юнит-тесты. Должны ли они отображать информацию о том, что они делают? Или тесты должны молчать и вообще не отображать какую-либо информацию о том, что они делают, а только отображать сообщения об ошибках?

ПРИМЕЧАНИЕ: язык C #, но мне не важен конкретный ответ.

Ответы [ 16 ]

4 голосов
/ 06 октября 2008

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

Это кажется абсолютно субъективным, но мне кажется, что это совершенно избыточная информация, которая только добавляет шум.

2 голосов
/ 06 октября 2008

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

2 голосов
/ 06 октября 2008

Я бы действительно предложил против этого (хотя и не воинственно). Он связывает пользовательский интерфейс ваших тестов с реализацией теста (что если тесты запускаются через GUI viewer?). В качестве альтернативы я бы предложил одно из следующего:

  1. Я не знаком с NUnit, но PyUnit позволяет добавить описание теста, а при запуске тестов с опцией verbose описание выводится на печать. Я бы заглянул в документацию NUnit, чтобы узнать, можно ли это сделать.
  2. Расширьте класс TestCase, от которого вы наследуете, чтобы добавить функцию, из которой вы вызываете, и записывает, что пытается сделать тест. Таким образом, разные реализации могут обрабатывать сообщения по-разному.
2 голосов
/ 06 октября 2008

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

2 голосов
/ 06 октября 2008

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

1 голос
/ 07 октября 2008

Вы смотрели на стиль модульных тестов xUnit?
Смотрите Рон Джеффрис сайт для довольно большого списка.

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

1 голос
/ 06 октября 2008

Я бы не стал добавлять дополнительные операторы Try / Catch в модульные тесты. Во-первых, ожидаемое исключение в модульном тесте уже приведет к сбою теста. Это стандартное поведение NUnit. По сути, тестовый набор уже оборачивает каждый вызов ваших тестовых функций этим кодом. Кроме того, просто используя e.ToString () для отображения того, что произошло, я считаю, что вы теряете много информации. По умолчанию я считаю, что NUnit будет отображать не только тип исключения, но и стек вызовов, который, как я полагаю, вы не видите в своем методе.

Во-вторых, бывают случаи, когда это необходимо. Например, вы можете использовать атрибут [ExpectedException], чтобы фактически сказать, когда это происходит. Просто убедитесь, что при тестировании связанных с неисключениями утверждений (например, Утверждение списка> 0 и т. Д.) Вы добавляете хорошее описание в качестве аргумента для утверждения. Это полезно.

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

1 голос
/ 06 октября 2008

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

Однако в «нормальном» случае, когда все удается, эти сообщения являются ненужным беспорядком, который отвлекает от того, что вы действительно пытаетесь сделать - т.е. посмотрим, какие тесты были успешными и неудачными.

Я бы предложил перенаправить ваши сообщения отладки в файл журнала. Вы можете сделать это, написав весь свой код сообщения журнала для вызова специальной функции «log print», или, если вы пишете консольную программу, вы сможете перенаправить стандартный вывод в другой файл (я точно знаю, что Вы можете сделать это как в Unix, так и в Windows). Таким образом, вы получите обзор высокого уровня, но детали есть, если они вам нужны.

1 голос
/ 06 октября 2008

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

1 голос
/ 06 октября 2008

Вам не нужно, если тесты выполняются без вывода сообщений, то это означает, что ошибки не было. У тестов обычно нет причин выдавать какие-либо результаты, кроме случаев, когда тест не пройден. Если он запущен, значит, он запущен, что указано исполнителем теста о том, что тест пройден, то есть он «зеленый». Запустив тест (вместе со многими тестами с выводом на консоль) через тестировщика в IDE, вы будете рассылать в консольный журнал сообщения, которые никому не нужны.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...