在 NUnit 2.5.8 中使用 TestContext 时出现 NullReferenceException
最近升级到 NUnit 2.5.8,以便使用新的 TestContext 功能。这样我们就可以确定当前的测试名称以检索属性:
private T GetAttribute<T>() where T : class
{
return Attribute.GetCustomAttribute(GetType().GetMethod(TestContext.CurrentContext.Test.Name), typeof(T)) as T;
}
但是,在访问属性 TestContext.CurrentContext.Test.Name 时,我们会看到 NullReferenceExceptions,因为 NUnit CallContext 似乎未正确注册。
有没有其他人遇到过这个问题,或者可以建议一种从设置中确定当前测试名称的替代方法?
Recently upgraded to NUnit 2.5.8 in order to use the new TestContext functionality. This is so that we can determine the current test name in order to retrieve an attribute:
private T GetAttribute<T>() where T : class
{
return Attribute.GetCustomAttribute(GetType().GetMethod(TestContext.CurrentContext.Test.Name), typeof(T)) as T;
}
However, we are seeing NullReferenceExceptions when accessing the property TestContext.CurrentContext.Test.Name because it seems that the NUnit CallContext is not being registered properly.
Has anyone else encountered this problem, or can suggest an alternative way of determining the current test name from the SetUp?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这不是您问题的答案,但我在使用 TestDriven.NET 的 xcopy-deployable NUnit 测试运行程序 使用 NUnit 2.5.7,并遇到
NullReferenceException
,因为TestDriven.NET 仍在 2.5.5(附带)下运行测试,而不是我的项目引用的 NUnit。问题原来是我在需要时引用了在
NUnit\NUnit-2.5.7.10213\bin\net-2.0
中找到的nunit.framework.dll
引用在NUnit\NUnit-2.5.7.10213\bin\net-2.0\framework
中找到的那个。我不知道为什么有两个副本,但指向正确的 DLL 就造成了一切不同。This isn't an answer to your question, but I came across a similar issue when using TestDriven.NET's xcopy-deployable NUnit Test Runner to use NUnit 2.5.7, and hitting a
NullReferenceException
because TestDriven.NET was still running the tests under 2.5.5 (which it ships with) and not the NUnit my project referenced.The problem turned out to be that I was referencing the
nunit.framework.dll
found inNUnit\NUnit-2.5.7.10213\bin\net-2.0
when I needed to be referencing the one found inNUnit\NUnit-2.5.7.10213\bin\net-2.0\framework
. Why there are two copies I have no idea, but pointing to the right DLL made all the difference.