Question

在浏览我的应用程序代码时，我遇到了这个问题：

private string[] ReadFromFile(string path)
{
    string[] data = null;
    try
    {
        data = File.ReadAllLines(path);
    }
    catch (Exception)
    {
        throw new Exception("The file is not correct");
    }

    return data;
}

好的，所以我知道这段代码不好，我正要重构这个。但是，此代码用于FitNesse的某些测试的定义。此代码在生产中使用从不。此方法中给出的参数应该始终正确。所以我想删除整个try / catch块，如果它应该让它崩溃。 FitNesse会给我们关于抛出异常的全部细节，但由于它是一个测试夹具，我想知道它是否可以 ok 。

File.ReadAllLines可以抛出十几种不同的例外。

所以我的问题是：在生产之外有这样的代码是否可以接受，即使用于测试生产代码，也在受控制的环境中？或者在任何情况下都不好？

Answer 1

在单元测试中使用此类代码比在生产代码中使用此代码更糟糕。在生产代码中，有时隐藏一些异常细节可能是有意义的（尽管它们仍应通过InnerException传递）但在单元测试中，您应该始终尽可能多地看到，因为它们是为完成的你（开发人员，而不是最终用户）。所以我认为应该删除整个try / catch块。

此外，如果在某些其他情况下您希望测试失败，那么我建议使用Assert.Fail("message")构造，因为它使得它更清晰，那么如果达到这一点，测试应被视为失败。不确定它是否可以应用于FitNesse。

Answer 2

我会抓住它，然后抛出一个简化的异常，它将利用FitNesse的功能

private string[] ReadFromFile(string path)
{
    string[] data = null;
    try
    {
        data = File.ReadAllLines(path);
    }
    catch (Exception)
    {
        throw new Exception("message:<<Problem reading in file: " +e.getMessage() + ">>");
    }

    return data;
}

如果执行此操作，错误消息将显示在上下文中，并且更易于识别。不幸的是，一个未解开的异常将出现在与出现问题的夹具分开的异常块中。 e.printStackTrace（）将为您提供有关输出页面的信息，可以为您提供更多详细信息。

我同意其他人的看法，在单元测试代码中，您希望在代码的上下文中发生异常。但是，在单元测试中，您的受众群体会有所不同。使用它的人应该始终是开发人员。在FitNesse测试的情况下，您正在与BA和测试人员合作，他们可能会受益于一些额外的诊断。

我添加的代码是Java，我知道这是一个c＃测试，但精神是相同的，并且“消息：＆lt;＆lt; exception”应该在FitSharp中用于slim。我在Java和ruby工作，所以我的c＃非常弱。

Answer 3

如果你发现异常，你应该对它做点什么，写下日志，例如如果只抛出自己的异常，则会丢失最后一个异常的堆栈跟踪。

在测试中抛出新的异常

3 个答案: