生成特定文本文件的类的重构策略

Question

我是TDD菜鸟，我不知道如何解决以下问题。 我有一个非常大的类，它以特定的格式生成文本文件，以便导入到外部系统。我要重构这个类，我想先写单元测试。

这些测试应该如何？实际上主要目标 - 不要破坏文件的结构。但这并不意味着我应该比较前后文件的内容？

Answer 1

在这种情况下，我使用以下策略：

• 为每个方法编写一个测试（只是覆盖其默认行为而不进行任何错误处理等）。

• 运行代码覆盖率工具，找到测试未涵盖的块。编写涵盖这些块的测试。

• 在您获得超过80％的代码覆盖率

之前执行此操作

• 开始重构类（主要是在关注原则分离后生成较小的类）。

• 使用测试驱动开发来编写新类。

Answer 2

实际上，这是一个非常好的起点（将众所周知的输出与当前类生成的输出进行比较）。 如果单个生成器类可以产生不同的结果，则为每种情况创建一个。 这将确保您不会破坏当前的生成器类。

如果您拥有当前类的规范文档，那么可能对您有所帮助的一件事就是。您可以将其作为重构工作的基础。

Answer 3

如果你还没有，请拿一本Michael Feathers的书“Working Effectively with Legacy Code”。这就是如何将测试添加到现有代码中，这正是您正在寻找的。

但是在你读完这本书之前，我建议从回归测试开始：创建类，让它将文件写入磁盘，然后将该文件与你已经存储的“已知好”文件进行比较在您的源存储库中的某个地方。如果它们不匹配，则测试失败。

然后开始研究你的班级做出的有趣决定。了解如何让他们接受测试。也许您将一些复杂的if条件提取到返回bool的公共函数中，并且您编写了一组测试来证明，如果输入正确，该函数将返回正确的值。也许生成一个特定的字符串有一些有趣的逻辑;开始测试它。

在此过程中，您可能会发现想要离开的物体。例如，如果有一个生成单行输出的单独类，您可能会发现代码（或测试！）会更简单。去吧。如果你搞砸了什么，你已经得到了回归测试来抓住你。

坚持不懈地去除依赖关系（但要确保你有一个更高级别的测试，比如回归测试，如果你犯错误就会抓住你）。如果您的类创建自己的FileStream并写入文件系统，请将其更改为在其构造函数中使用TextWriter，这样您就可以编写传递给StringWriter的测试，而不会触及文件系统。完成后，您可以摆脱将文件写入磁盘的旧测试（但只有在尝试编写新测试时没有破坏它！）如果您的类需要数据库连接，请重构直到您可以编写传递假数据的测试。等

Answer 4

我认为你会受益于我会毫不犹豫地称之为“单元测试”的测试 - 尽管可以说它会测试当前产生文本文件的“单元”。这将简单地运行当前代码并在其输出和“黄金主”文件之间进行差异（您可以通过运行测试一次并复制到其指定位置来生成）。如果代码中有很多条件行为，您可能希望使用几个示例来运行它，每个示例都是不同的测试用例。根据定义，现有代码应该通过所有测试。

现在开始重构。提取方法 - 或者更好，为可以设想提取的方法编写测试，真正的单元测试 - 提取方法，并确保所有测试，对于新的小方法和更大的系统，仍然通过。泡沫，冲洗，重复。系统测试为您提供了一个安全网，让您可以放心地进行重构;单元测试驱动新代码的设计。

有一些库可以使这种测试变得更容易（尽管即使没有它们也很容易）。请参阅http://approvaltests.sourceforge.net/。