4

考虑以下测试输出：

通过测试规范说明我的情况`

总而言之，不支持 Word 文档，而支持 PDF。所以我们立即拒绝 Word 文档。但是对于 PDF，还有更多的步骤需要测试，所以我们这样做了。

问题是，假设我还想支持文本文件，它具有与 PDF 完全相同的工作流程。我正在测试的代码基本上如下所示：

function uploadDocument(type, document) {
    if (type !== "application/pdf" && type !== "text/plain") {
        throw new UnsupportedMediaTypeError();
    }

    // do all the steps involving temp documents, hashing, ownership, etc.
}

我的问题是：我怎样才能为此构建我的测试？我不想将“上传 PDF 时”下面的整个树复制为“上传文本文件时”。

我觉得我经常遇到这个问题。如您所见，我已经做了一些重复（“删除临时文档成功”和“提交临时文档成功”下的条目是相同的）。

本质上，这是一个改变系统的多个维度并组合测试它们的问题。一定有人想到了如何构建这样的测试。

4

2 回答 2

1

我似乎需要将其分解为 2 个测试（可能更多，但这是一个不同的主题）

Given A document of type <doc_type> 
Then it should have an allowed status of  <status>

Examples:
| doc_type | status  | 
| word      | fail   | 
| text      | accept | 
| pdf       | accept |

然后您的测试将简化为

...
when uploading a valid file type
...

快乐测试，卢埃林

于 2012-06-11T12:12:58.367 回答
0

我通过以下方式理解您的示例：

  • 您区分支持和不支持的媒体类型。
  • 所有不受支持的媒体的行为都是相同的
  • 所有支持的媒体的行为都是相同的
  • 对于支持的媒体，使用内容，但仅作为原始字节（散列）

因此，对不同类型的支持媒体执行两次测试似乎没有什么价值。让我解释一下您可能正在使用的不同可能的开发过程：

A. 可能性 如果您正在执行 BDD，那么选择测试来“驱动”您的实现。但是，在您为 pdf 实现所有内容之后，代码已经到位。您只需要一个额外的测试用例来“驱动”您添加&& type !== "text/plain"分数。对于来自重复树的所有其他测试，您不会添加任何额外的代码。因此，来自复制树的测试没有“驱动”特性。

可能性 B. 您正在做测试用例设计，只需使用 BDD 表示法来制定您的测试。在这种情况下，您的目标是定义一个可以发现可能的错误的测试套件。您对代码有白盒知识，这意味着您知道对 pdf 和文本文件的处理是相同的。因此，您只需要为 pdf 文件和文本文件制作不同的测试用例，这可能会发现额外的错误。这里可能有一些场景，例如，如果文件扩展名可能会阻止它被存储 - 但很可能并非对于所有场景，区别都是相关的。

可能性 C. 最后，还有一个类似于 b 的可能场景，但您没有白盒知识。鉴于在您的示例测试用例内部是如何讨论的，这并不适合您的示例，因此我不会对此进行详细说明。

在讨论了测试级别之后，还需要在设计级别上提到一些内容：您的代码 a) 区分受支持和不受支持的媒体，b) 处理所有受支持的媒体。它在同一个函数中完成所有这些，这甚至可能是您最初考虑复制测试的原因：由于在这个大函数中参数type和document可访问性，有人甚至可能type在处理部分使用，使其不太常见。您可能会考虑在单独的函数中处理不同的职责，然后单独测试这些函数：一个函数确定是否支持类型（仅使用type参数），一个函数处理支持的文档（仅使用document参数）。

于 2019-01-14T20:38:39.507 回答