Пропустить модульные тесты, которые занимают много времени

Я работаю с MS-Test для написания модульных тестов. Большинство моих тестов имеют продолжительность менее 0,1 секунды. Я хочу как-то сказать VS «игнорировать тесты, которые занимают много времени, когда я запускаю тесты вручную, и когда вы запускаете их на сборке, не игнорируйте их.Пропустить модульные тесты, которые занимают много времени

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

помогите пожалуйста

источник

2010-09-21 Chen Kinnrot

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

Я знаю, но тесты хорошие, и я хочу как-то пропустить их по умолчанию при ручном запуске теста и позволить серверу запускать их после проверки. –

Например, хороший тест, который занимает много времени, - это сборка калибровочной проверки для события EventChanged, которая занимает 3 секунды. –

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

источник

2010-09-21 12:21:15

Да, как это

<TestMethod(), Timeout(1000)> 
    Public Sub OutputWebservice_SubmitOutputJob_SubmitEmailJobHF001() 
    End Sub

источник

2010-09-21 12:28:57 Iain

Но я не хочу, чтобы тест потерпел неудачу, я просто хочу пропустить его автоматически на моей клиентской машине. Тест прошел нормально –

было бы классифицировать как таймаут не сбой – Iain

ОК, но это занимает много времени, скажем, я получил 1000 модульных тестов и 100 из них - длинные тесты, а таймаут - 1 сек, поэтому я буду записывать 2 минут ни для чего? Эти 2 минуты заставят разработчиков пропустить запуск модульного теста перед фиксацией. –

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

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

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

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

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

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

НТН

источник

2010-09-21 12:58:17 bguiz

Привет, спасибо за всю информацию, я ищу больше технических материалов, вы можете написать некоторые или поместить некоторые ссылки на свои инструменты? –

Конкретные инструменты, которые я использую, не будут полезны для вас, так как они не являются Microsoft или Visual Studio. H/w на случай, если вам интересно, они будут CruiseControl для непрерывной интеграции и JUnit/FEST в качестве тестовых инструментов. Подумайте об этом, возможно, вы можете сделать то же самое с помощью CruiseControl.NET и любого инструмента тестирования, совместимого с xUnit. НТН. Всего наилучшего! – bguiz

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

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

источник

2010-09-25 15:32:27 RJFalconer

Мне нравится ваша идея, но я хочу, чтобы разработчик запускал некоторые вещи перед фиксацией –

Пропустить модульные тесты, которые занимают много времени

ответ

Смежные вопросы