如何在执行之前确定单元测试的名称?
我正在使用 MSTest,一切都很好。不久前,我需要编写大量数据驱动的单元测试。
此外,我需要在运行测试之前知道测试的名称,以便我可以使用正确的参数(从外部远程服务获取)填充数据源。
在 MSTest 中,我无法找到一种方法来获取在实际执行之前即将运行的测试的名称。当然,此时已经太晚了,因为数据源已经填充了。
我需要的是知道即将执行的测试的名称,以便我可以在执行之前提前配置它们的数据源。
有人建议我“看看 NUnit”。我对 NUnit 完全一无所知。现在我已经开始阅读它的文档但仍然不知所措。你有什么建议吗?
I was using MSTest and all was fine. Not long ago, I needed to write a large number of data driven unit tests.
Moreover, I needed to know the name of the test just before I run it, so I could populate the data sources with the correct parameters (that were fetched from an external remote service).
Nowhere in MSTest could I find a way to get the name of the tests that are about to run before their actual execution. At this point it was, of course, already too late, since the data sources were already populated.
What I need is to know the names of the test that are about to execute so I could configure their data sources in advance, before their execution.
Somebody suggested I "check out NUnit". I am completely clueless about NUnit. For now I have started reading its documentation but am still at a loss. Have you any advice?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
如果您确实需要测试的名称——它没有很好的文档记录,但 NUnit 公开了一个功能,可以让您访问当前的测试信息:
提供:
请注意,此功能不能保证由自定义 TestRunner(如 ReSharper)实现。我已经在 NUnit 2.5.9(nunit.exe 和 nunit-console.exe)中对此进行了测试
,但是,重新阅读您的问题我认为您应该检查一下 TestCaseSource 或 TestCase 属性,可用于参数化测试。
If you really need the test's name -- It's not well documented, but NUnit exposes a feature that let's you get access to the current test information:
Provides:
Note this feature isn't guaranteed to implemented by custom TestRunners, like ReSharper. I have tested this in NUnit 2.5.9 (nunit.exe and nunit-console.exe)
However, re-reading your question I think you should check out is the TestCaseSource or TestCase attribute that can be used to parameterize your tests.
如果我正确理解您的问题,您希望获取当前正在运行的测试的名称,以便可以将其用作查找一组数据的键,用于填充被测代码使用的数据源。是这样吗?
如果是这种情况,那么我认为您不需要在单元测试框架中寻找特殊功能。为什么不使用 Reflection API 来获取当前正在执行的方法的名称?
System.Reflection.MethodBase.GetCurrentMethod()< /code>
将为您提供
MethodBase
对象表示方法,并且具有Name
属性。但是,我建议使用方法名称作为查找适当测试数据的键是一个坏主意。您会将方法的名称与您的数据集耦合起来,这对我来说似乎是脆弱代码的秘诀。您需要自由地重构代码和方法名称,而不必担心这是否会破坏后台的数据库查找。
作为替代方案,为什么不考虑创建自定义属性 您可以使用它来标记那些需要数据库查找的测试方法,并使用该属性上的属性来保存密钥?
If I'm understanding your problem correctly, you want to get the name of the currently-running test so that you can use it as a key to look up a set of data with which to populate the data sources used by the code under test. Is that right?
If that's the case then I don't think you need to look for special functionality in your unit testing framework. Why not use the Reflection API to fetch the name of the currently-executing method?
System.Reflection.MethodBase.GetCurrentMethod()
will get you aMethodBase
object representing the method, and that has aName
property.However, I'd suggest that using the method name as a key for looking up the appropriate test data is a bad idea. You'd be coupling the name of the method to your data set, and that seems like a recipe for fragile code to me. You need to be remain free to refactor your code and the names of methods without worrying about whether that will break the database lookup behind-the-scenes.
As an alternative, why not consider creating a custom Attribute that you can use to mark those test methods that need a database lookup, and using a property on that attribute to hold the key?
对于这样的事情,您应该依靠夹具在运行测试之前初始化您想要的状态。
在(任何)测试框架中工作的最简单方法是创建一个夹具,用于加载给定数据标识符的任何数据(字符串)。然后,在每个测试用例中,您只需提供用于在该测试中查找所需数据的数据查找的测试字符串。
除此之外,不建议让单元测试访问文件和其他外部资源,因为这意味着更慢的单元测试和更高的失败概率(因为您依赖于内存中代码之外的东西)。这当然取决于您拥有的数据量和您正在进行的测试类型,但我通常会编译数据以进行单元测试。
For things like this you should rely on a fixture to initialize the state you want before you run the test.
The simplest way which works in (any) testing framework is to create a fixture which loads any data given a data identifier (string). Then in each test case you just provide the test string for data lookup for the data you want in that test.
Aside from this, it's not recommended to have unit tests access files and other external resources because it means slower unit tests and higher probability of failure (as you're relying on something outside the in-memory code). This of course depends on the amount of data you have and the type of testing you're doing, but I generally have the data compiled-in for unit tests.