14、命令行应用程序测试：从集成测试到单元测试

命令行应用程序测试：从集成测试到单元测试

1. 测试面临的挑战

在测试命令行应用程序时，我们前期主要采用模拟用户操作的方式运行应用程序进行测试，这种方式能让我们清晰了解应用程序的预期工作方式，甚至可以将 Cucumber 特性作为补充文档。然而，当需要测试边缘情况时，Cucumber 的局限性就显现出来了。

以 todo 应用为例，可能会遇到以下问题：
- 待办事项列表格式不正确怎么办？
- 添加新任务时任务列表文件不可写怎么办？
- 应用程序会如何响应？应该如何响应？

为了测试 todo ，我们在模拟主目录时付出了不少努力，而要模拟所有边缘情况的条件会更加困难，甚至可能无法实现。因此，我们需要将代码分解为更小的、可测试的单元，这种测试类型被称为单元测试。

2. 单元测试的优势

单元测试除了在模拟边缘情况时具有更大的灵活性外，还有另外两个优点：
- 运行速度快 ：单元测试不需要 Ruby 之外的任何设置（如文件、数据库等），因此运行速度很快。这样我们可以更快地了解应用程序的健康状况，在编写新功能和修复 bug 时更频繁地运行测试。
- 代码更易维护 ：单元测试迫使我们将代码组织成小的、可测试的单元。这意味着我们的应用程序将更容易理解和维护，因为我们拥有的是一个个完成简单任务的小单元，它们组合在一起构成了整个应用程序。

3. 从现有代码中提取单元

todo 的源代码围绕 GLI 命令