如果未找到 csv 文件,则跳过单元测试
我有许多单元测试依赖于 csv 文件的存在。如果该文件明显不存在,他们将抛出异常。
是否有任何 Gallio/MbUnit 方法可以有条件地跳过测试运行?我正在运行 Gallio 3.1 并使用 CsvData 属性
[Test]
[Timeout(1800)]
[CsvData(FilePath = TestDataFolderPath + "TestData.csv", HasHeader = true)]
public static void CalculateShortfallSingleLifeTest()
{
.
.
.
谢谢
I have a number of unit tests which rely on the presence of a csv file. They will throw an exception if this file doesn't exist obviously.
Are there any Gallio/MbUnit methods which can conditionally skip a test from running? I'm running Gallio 3.1 and using the CsvData attribute
[Test]
[Timeout(1800)]
[CsvData(FilePath = TestDataFolderPath + "TestData.csv", HasHeader = true)]
public static void CalculateShortfallSingleLifeTest()
{
.
.
.
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
根据这个问题中的答案,您'如果文件丢失,您需要创建一个新的
TestDecoratorAttribute
来调用Assert.Inconclusive
。Assert.Inconclusive
非常适合您的情况,因为您并不是说测试通过或失败;你只是说它无法在当前状态下执行。According to the answer in this question, you'll need to make a new
TestDecoratorAttribute
that callsAssert.Inconclusive
if the file is missing.Assert.Inconclusive
is very appropriate for your situation because you aren't saying that the test passed or failed; you're just saying that it couldn't be executed in the current state.您这里的不是单元测试。单元测试测试单个代码单元(尽管它可能很大),并且不依赖于外部环境因素,例如文件或网络连接。
由于您依赖于此处的文件,因此您拥有的是集成测试。您正在测试您的代码是否与代码控制之外的某些内容(在本例中为文件系统)安全地集成。
如果这确实是集成测试,您应该更改测试,以便测试您真正想要测试的内容。
如果您仍然将其视为单元测试,例如您正在尝试测试 CSV 解析,那么我将重构代码,以便您可以模拟/存根/伪造 CSV 文件内容的实际读取。这样您就可以更轻松地向 CSV 解析器提供测试数据,而不依赖于任何外部文件。
例如,您是否考虑过:
一旦开始涉及文件系统等外部系统、网络连接等。有很多事情可能会出错,所以你所做的基本上是一个脆弱的测试。
我的建议:找出您要测试的内容(文件系统?CSV 解析器?),并删除与该目标相冲突的依赖项。
What you have here is not a unit test. A unit test tests a single unit of code (it may be large though), and does not depend on external environmental factors, like files or network connections.
Since you are depending on a file here, what you have is an integration test. You're testing whether your code safely integrates with something outside of the control of the code, in this case, the file system.
If this is indeed an integration test, you should change the test so that you're testing the thing that you actually want tested.
If you're still considering this as a unit test, for instance you're attempting to test CSV parsing, then I would refactor the code so that you can mock/stub/fake out the actual reading of the CSV file contents. This way you can more easily provide test data to the CSV parser, and not depend on any external files.
For instance, have you considered that:
Once you start involving external systems like file systems, network connections, etc. there's so many things that can go wrong that what you have is basically a brittle test.
My advice: Figure out what you're trying to test (file system? CSV parser?), and remove dependencies that are conflicting with that goal.
一种简单的方法是在测试开始时包含一个 if 条件,如果可以找到 CSV 文件,则仅执行测试中的任何代码。
当然,这有一个很大的缺点,即测试将是绿色的,尽管它们实际上没有运行并断言任何内容。
不过,我同意 Grzenio 的观点,如果您的单元测试严重依赖外部条件,那么它们并不能真正帮助您。在这种情况下,您永远不会真正知道单元测试是否成功运行或只是被跳过,这与单元测试的实际用途相矛盾。
以我个人的观点,我只会编写测试,以便在文件不存在时它们正确地失败。如果失败,则表明有问题的文件应该在运行单元测试的计算机上可用。有时这可能需要一些手动调整(将文件发送到有问题的计算机或服务器),但至少您有可靠的单元测试。
An easy way would be to include an if condition right at the start of the test that would just execute any code in the test if the CSV file can be found.
Of course this has the big drawback that tests would be green although they haven't actually run and asserted anything.
I agree with Grzenio though, if you have unit tests that rely heavily on external conditions, they're not really helping you. In this scenario you will never really know whether the unit test ran successfully or was just skipped, which contradicts what unit tests are actually for.
In my personal opinion, I would just write the test so that they correctly fail when the file is not there. If they fail this is an indicator that the file in question should be available on the machine where the unit tests run. This might need some manual adjustments at times (getting the file to the computer or server in question), but at least you have reliable unit tests.
在 Gallio/MbUnit v3.2 中,抽象
ContentAttribute
及其具体派生类型(例如 < code>[CsvData] 有一个新的可选参数,允许在打开或读取文件数据源时发生错误时更改测试的默认结果(参考问题 681)。语法如下:In Gallio/MbUnit v3.2 the abstract
ContentAttribute
and its concrete derived types (such as[CsvData]
have a new optional parameter that allows to change the default outcome of a test in case of an error occured while opening or reading the file data source (ref. issue 681). The syntax is the following: