1

我现在正在编写一个解析 epub 文件的程序（基本上是一个带有一些 xml 元数据文件的 zip）。该程序适用于我测试过的所有输入文件。

尽管如此，我还是想编写一些测试（单元测试或行为测试）以确保它适用于所有文件并拥有“更好的代码”。

实现 EPUB 规范并为测试提供一些 XML 片段的唯一方法是完美地（至少在理论上）吗？

我对一般测试很熟悉，但我从来没有对将文件作为输入的东西进行测试，所以我也在寻找更多关于它的信息。:)

4

2 回答 2

2

单元测试方法是消除测试中的外部依赖。这样，运行测试不需要你的环境做任何事情，除了托管你的测试程序。

在您的代码中，大多数情况下您不应该对“testfile.epub”感兴趣。这只是 OpenEpubFile() 例程的工作。相反，您有兴趣测试“这里是一个指向一些数据的指针，我如何解压缩它？”的具体逻辑。或“我如何处理标题标签？” 因此，您的单元测试将提供示例压缩数据来测试您的解压缩逻辑是如何工作的，并提供示例标题标签来查看您的逻辑如何处理标题。您将传递给它的标题很好，很长，很短，格式错误，您将提供执行您需要在代码中测试的任何逻辑所需的不同类型的数据。但是这些数据不必每次都来自文件，它可以来自测试工具。

如果你发现你的逻辑很难测试，这可能表明是时候模块化它了。您需要将打开文件的代码与读取数据的代码分开。您需要将读取数据的代码与解压缩数据的代码分开。您需要将解压缩数据的代码与解析 XML 的代码分开。您需要将构建屏幕的代码与绘制屏幕的代码分开。提取方法重构过程以及重命名方法在这里将非常有用。而且您将严重依赖依赖倒置模式。

每次您可以将其分解为实现纯逻辑的无状态代码时，您都可以非常轻松地测试这些规则。更好的是，当您将其分解为所需的模块时，您会发现添加新模块来处理新案例变得更加容易，因为您可以重复现有模式。

是的，在某个时候，您将进行一项测试，以确保您的 open() 语句实际上可以打开文件。在单元测试代码通过所有测试之后，就该进行集成测试了。在那里，您可以为其提供一组真实的 .epub 文件并查看输出是否符合要求。

于 2012-11-21T21:53:50.510 回答
0

无需为了测试而重新实现 .epub。

创建一些小的 .epub 文件来展示某些特征，并针对这些特征创建测试。

于 2012-11-21T18:20:49.773 回答