2015-05-19 2 views
1

Пример:C# Как я могу ожидать исключения в Assert.AreEqual?

Assert.AreEqual(**null**, Program.nDaysMonth(5, -10), "Error nDaysMonth, Month may -10."); 

Я ожидал исключение. Как я могу ожидать исключения в Assert.AreEqual?

Спасибо.

+2

Если вы ожидаете, исключение, поэтому использовать 'Assert'?Почему бы не украсить ваш метод «ExpectedException»? –

+0

См. Http://stackoverflow.com/questions/933613/how-do-i-use-assert-to-verify-that-an-exception-has-been-thrown - если это не соответствует вашим потребностям, добавьте дополнительная информация о том, почему нет. – tolanj

+0

Вы спрашиваете, как написать модульный тест, чтобы проверить, что 'Program.nDaysMonth (5, -10)' выдает исключение? – juharr

ответ

6

Вы не используете Assert.AreEqual, вы используете Assert.Throws:

Assert.Throws<ArgumentOutOfRangeException>(() => Program.nDaysMonth(5, -10)); 

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

var exception = Assert.Throws<ArgumentOutOfRangeException>(...); 
Assert.AreEqual("Foo", exception.Message); // Or whatever 

Это работает, по крайней мере NUnit и XUnit; если вы используете другую структуру тестирования, вы должны искать аналогичную функциональность. Если этого не существует, я бы рекомендовал его реализовать самостоятельно - это достаточно легко сделать и намного чище, чем альтернативы (блок try/catch или атрибут ExpectedException). С другой стороны, рамки модульного тестирования изменения, если вы можете ...

Я также сильно советует вам начать следовать обычным соглашениям .NET именования - nDaysMonth является не хорошего имени методы ...

Некоторые структуры поддерживают декорирования метод с атрибутом [ExpectedException] - я бы рекомендовал против с помощью этого:

  1. Это делает тест мутноватый о том, где вы ожидаете, что исключительные возможности чтобы быть брошенным.
  2. Если исключение выбрано в другом месте метода тестирования (т. Е. Ваш код не работает), тест все равно пройдет.
  3. Вы не можете ничего сделать после исключения.
  4. Вы ничего не можете проверить об исключении.
+2

['Assert'] (https://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.assert.aspx) не имеет метода под названием' Throws'. Или я что-то пропустил? –

+2

@oleksii: 1) Это делает тест непонятным, где вы ожидаете, что исключение будет выброшено. 2) Если исключение выбрано в другом месте тестового метода (т. Е. Ваш код сломан), тест все равно пройдет. 3) Вы не можете делать ничего другого после того, как будет выбрано исключение. 4) Вы ничего не можете проверить об исключении. В принципе, это плохая идея. –

+0

@oleksii Что вы имеете в виду, зависит от структуры? –

0

Если вы используете рамки теста Microsoft, вам нужно будет украсить метод с ExpectedExceptionAttribute:

[TestClass] 
public class UnitTest1 
{ 
    [TestMethod] 
    [ExpectedException(typeof(ArgumentOutOfRangeException))] 
    public void TestMethod1() 
    { 
     //Do whatever causes the exception here 
    } 
} 

Испытания будет проходить или не в зависимости от выброса исключения или нет.

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

Я рекомендую NUnit, http://www.nunit.org/

Или есть другие, как XUnit https://github.com/xunit/xunit

или буквально десятки других: http://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#.NET_programming_languages

+0

Это плохая идея (IMO) по причинам, указанным в комментарии в моем ответе. Ограничение объема ожидаемого исключения по отношению к выражению лямбда * очень * более чистое ИМО. –

+0

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

+0

Вряд ли вам нужно * украсить метод атрибутом, не так ли? Это просто, если вас не беспокоит переопределение «Assert.Throws» - что довольно просто и делает все остальные ваши тесты более ясными, IMO. Я бы определенно рекомендовал сделать это (или переключиться на тестовую структуру, которая не застряла в прошлом ...) –

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