我发现,那个简单的单元测试
[TestMethod()]
[ExpectedException(typeof(ArgumentException))]
public void UT_UU()
{
}
给出了错误
消息:测试方法没有抛出预期的异常 System.ArgumentException。
我成功使用[ExpetedException]来测试错误消息输出,但是,在单元测试中使用Assert of side variables进行的任何检查都会导致出现故障。
我可以以某种方式装饰我的测试以避免它吗?或者是“政治错误”?
答案 0 :(得分:1)
[ExpectedException(typeof(ArgumentException))]
的只有当被测方法生成您指定的类似类型的异常时,才会通过单元测试。在您的情况下ArgumentException
,否则它将失败并显示您发布的消息。
基本上,您必须通过注入该异常来使用该注入失败您的测试方法。目前,您的测试方法不会抛出预期的异常(它实际上不执行任何操作)
例如下面的测试方法将通过
[TestMethod()]
[ExpectedException(typeof(ArgumentException))]
public void UT_UU()
{
throw new ArgumentException();
}
答案 1 :(得分:1)
如果您的测试足够孤立,只能测试一件事,那么在ExpectedException修饰的测试主体中使用Assert语句并不能很好地适应模式。如果您遵循"安排,行动,断言"在这种情况下,Assert由ExpectedExceptionAttribute本身处理,并且测试本身的最后一行代码将是" Act"因为它应该导致异常发生。如果您需要了解有关抛出的异常的更具体的内容以确保系统满足行为期望,那么我将在测试中使用try / catch来提供更细粒度的检查:
[TestMethod]
public void UT_UU()
{
// Arrange
var subject = new Foo();
try
{
// Act
subject.Bar();
}
catch(ArgumentException ae)
{
Assert.AreEqual("my message", ae.Message);
return;
}
catch(Exception e)
{
Assert.Fail("Thrown exception was of wrong type"); // would provide more detail here
}
Assert.Fail("exception should have been thrown");
}
显然只是使用ExpectedException很好,因为它可以让你在没有额外噪音的情况下进行非常干净的测试。或者,如果您要重新使用这种类型的测试,您可以编写ExpectedException的衍生物,它允许您指定其他特征(如Message)来检查而不仅仅是类型。