Должны ли вы отображать, что происходит в модульном тесте во время его работы?

Question

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

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 #, но мне не важен конкретный ответ.

Answer 1

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

Answer 2

Мне нравится буферизовать подробный журнал (примерно последние 20 строк или около того), но я не отображаю его, пока не произойдет какая-либо ошибка. Когда происходит ошибка, неплохо иметь некоторый контекст.

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

Answer 3

Вы могли бы написать такой метод испытаний. Какой стиль теста вы предпочитаете, зависит от вашего кода. Я предпочитаю не писать дополнительные try-catches и Console.WriteLines.

public void TestApplicationStart()
{
  InteropApplication application = new InteropApplication(true);
  application.Start();
}

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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