У меня есть следующая проблема: я знаю, что в NUnit есть атрибут Timeout. Моя проблема в том, что модульные тесты фактически порождают новый процесс, который, если заморозить, никогда не будет убит NUnit. Как я могу реализовать тайм-аут, который фактически избавится от процесса изгоев?
Спасибо, R.
Вы можете использовать таймаут для утверждения вместо таймаута для всего тестового метода:
Assert.That(actual, Is.EqualTo(expected).After(5000, 50));
Изменить: Принятый ответ лучше.
Если ваш тест в конечном итоге истекает (хотя и позже, чем вы надеетесь), вы всегда можете использовать атрибут MaxTime: http://www.nunit.org/index.php?p=maxtime&r=2.5.1 и самостоятельно очистите резьбу:
[Test, Maxtime(2000)]
public void TimedTest()
{
...
}
В противном случае лучшим вариантом может быть реализация собственного механизма синхронизации. Используйте таймер (или занятый цикл while), и если превышен тайм-аут, то убейте этот процесс (возможно, в методе ShutDown, если он является общим для тестов) и сбой сигнала.
Таймауты NUnit не имеют никаких событий, которые позволяют запускать код после истечения времени тестирования. Вы должны катиться самостоятельно, похоже.
OK. После того, как я пробовал все функции, встроенные в NUnit, и не смог добиться того, что мне было нужно, я сделал следующее: я добавил таймер, который устанавливается в функции, присваиваемой [SetUp] на уровне прибора и, таким образом, вызывается перед каждый тест. Если таймер гаснет до завершения теста, я просто делаю очистку в обратном вызове таймера.
[Test, Timeout(2000)]
public void PotentiallyLongRunningTest()
{
...
}
http://www.nunit.org/index.php?p=timeout&r=2.5.1:
TimeoutAttribute используется для указания значения тайм-аута в миллисекундах для тестового примера. Если тестовый пример работает дольше, чем указанное время, он немедленно отменяется и сообщается как сбой, с сообщением о превышении таймаута.
Атрибут также может быть указан на приборе или сборке, и в этом случае он указывает время ожидания по умолчанию для любых подчиненных тестовых случаев.