如果未找到 csv 文件,则跳过单元测试

发布于 2024-09-08 04:14:17 字数 333 浏览 6 评论 0原文

我有许多单元测试依赖于 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

写下不归期 2024-09-15 04:14:17

根据这个问题中的答案,您'如果文件丢失,您需要创建一个新的 TestDecoratorAttribute 来调用 Assert.Inconclusive

Assert.Inconclusive 非常适合您的情况,因为您并不是说测试通过或失败;你只是说它无法在当前状态下执行。

According to the answer in this question, you'll need to make a new TestDecoratorAttribute that calls Assert.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.

七色彩虹 2024-09-15 04:14:17

您这里的不是单元测试。单元测试测试单个代码单元(尽管它可能很大),并且不依赖于外部环境因素,例如文件或网络连接。

由于您依赖于此处的文件,因此您拥有的是集成测试。您正在测试您的代码是否与代码控制之外的某些内容(在本例中为文件系统)安全地集成。

如果这确实是集成测试,您应该更改测试,以便测试您真正想要测试的内容。

如果您仍然将其视为单元测试,例如您正在尝试测试 CSV 解析,那么我将重构代码,以便您可以模拟/存根/伪造 CSV 文件内容的实际读取。这样您就可以更轻松地向 CSV 解析器提供测试数据,而不依赖于任何外部文件。

例如,您是否考虑过:

  • 防病毒软件包可能无法让您立即访问该文件
  • 典型的程序员工具(如 TortoiseSvn)将 shell 覆盖层集成到资源管理器中,有时会保留文件太长时间,并且并不总是提供对文件的访问权限。一个文件到一个程序(您删除了该文件,并尝试用新文件覆盖它?当然,让我先完成删除操作,但是有一个程序保留该文件,因此可能需要一段时间.. .)
  • 该文件实际上可能不存在(为什么?)
  • 您可能没有对该路径的读取访问权限
  • 您可能有错误的文件内容(早期调试会话留下的内容?)

一旦开始涉及文件系统等外部系统、网络连接等。有很多事情可能会出错,所以你所做的基本上是一个脆弱的测试。

我的建议:找出您要测试的内容(文件系统?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:

  • An AntiVirus package might not give you immediate access to the file
  • A typical programmer tool, like TortoiseSvn, integrates shell overlays into Explorer that sometimes hold on to files for too long and doesn't always give access to a file to a program (you deleted the file, and try to overwrite it with a new one? sure, just let me get through the deletion first, but there is a program holding on to the file so it might take a while...)
  • The file might not actually be there (why is that?)
  • You might not have read-access to the path
  • You might have the wrong file contents (leftover from an earlier debugging session?)

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.

海螺姑娘 2024-09-15 04:14:17

一种简单的方法是在测试开始时包含一个 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.

梦太阳 2024-09-15 04:14:17

Gallio/MbUnit v3.2 中,抽象 ContentAttribute 及其具体派生类型(例如 < code>[CsvData] 有一个新的可选参数,允许在打开或读取文件数据源时发生错误时更改测试的默认结果(参考问题 681)。语法如下:

[Test]
[CsvData(..., OutcomeOnFileError = OutcomeOnFileError.Inconclusive)]
public void MyTestMethod()
{
  // ...
}

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:

[Test]
[CsvData(..., OutcomeOnFileError = OutcomeOnFileError.Inconclusive)]
public void MyTestMethod()
{
  // ...
}
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文