Использование Console.Out.WriteLine vs Trace.WriteLine в nUnit либо выполняется изолированно, либо в reSharper или TeamCity

Question

Я смутно помню, как читал «что-то» «где-то» об использовании Trace.WriteLine над Console.Out.WriteLine в nUnit, возможно, в контекст reSharper или TeamCity, но я не могу запомнить детали.

Таким образом, вопрос заключается либо в контексте nUnit, выполняемого отдельно, либо в рамках reSharper/TeamCity, есть ли какая-либо польза от использования одного над другим, каковы различия, если таковые имеются, и что вы лично используете?

В настоящее время моя точка зрения - Trace.WriteLine не только потому, что я смутно помню то, о чем я мог мечтать, но я чувствую, что трассировка в модульном тесте - скорее задача диагностики, чем задача вывода.

Answer 1

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

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

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

четыре варианта сделать следующее ^ref:

• Стандартный выход: Захватывает весь вывод записывается в console.error ,
• Ошибка: Захватывает весь вывод, записанный на Console.Error.
• Выход трассировки: Захватывает весь вывод, записанный в Trace или Debug.
• Выход журнала: Записывает вывод, записанный в журнал log4net. NUnit фиксирует все выходные данные на уровне ошибки или выше, если не указан другой уровень для параметра DefaultLogThreshold в файле конфигурации для тестовой сборки или проекта.

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

Я не знаю ни одной подобной настройки в тестовом бегуре ReSharper.

_{Одно дело также стоит учитывать, что вывод текста может иметь побочные эффекты. Недавно я столкнулся с сбоем NUnit, потому что в каком-то выпуске содержались символы, которые были незаконными в файле XML - NUnit производит один из них как часть нашего автообмена.}

---

EDIT:

@Bronumski: Единственное реальное различие я вижу в использовании одного метода над другим является способ вывода потребляется.

Некоторые инструменты подберут Debug трассировку (например, DebugView), но не Console. Кроме того, вы можете отключить вывод Trace во время выполнения через конфигурацию (в файле app.config), но не Console. Это будет иметь значение только в том случае, если вам нужно украсить реальный (т. Е. Не тестовый) код с трассировкой для ваших тестов - регистрация лотов текста во время выполнения может быть дорогостоящим, и это выгодно, если его можно отключить, если он вам не нужен что-то диагностировать.

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

Answer 2

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

Answer 3

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

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

Я нашел этот отрывок из здесь, если это помогает:

http://www.interviewcorner.com/Answer/Answers.aspx?QuestionId=268&MajorCategoryId=1&MinorCategoryId=16

EDIT: Расположенный еще немного интересной информации упоминает след с использованием многоадресной рассылки, значит ли это означает, что все, что реализует она будет фиксировать след написать строку?

Прочитайте и дать обратную связь, пожалуйста:

http://www.drdobbs.com/184405769;jsessionid=SFAYCN2R2Y3L5QE1GHRSKH4ATMY32JVN