如何在 TDD 中测试环境？答案

【问题标题】：How to test the environment in TDD?如何在 TDD 中测试环境？
【发布时间】：2013-05-17 09:57:57
【问题描述】：

随着我继续学习和应用 TDD，我遇到了一些我不知道如何在编写代码之前进行测试的点（我应该这样做）。
它适用于我的应用程序之外的任何内容，例如测试：

我如何测试这些东西？

编辑：
我想专注于第一个示例，因为我正在开发一个实际需要这些测试的应用程序。如何测试文件的更改？

【问题讨论】：

【解决方案1】：

任何依赖于环境的测试都不是单元测试，而是集成测试。 TDD 不适用于这些。

当然，您可以创建集成测试，而且您当然可以在编写测试代码之前编写这些测试。

【讨论】：

你能再给我一点吗？集成测试这个词对我来说是新的。我确实查过了，但我看不出它如何适合我的情况（鉴于我对文件系统/Windows 进程模块几乎没有控制权）。
单元测试测试一个小的功能单元，独立于该单元所依赖的任何东西。集成测试测试两个或多个组件如何协同工作。例如，您的数据访问代码如何与数据库一起使用。
好的，那么你们如何确保可以写入数据库，并且不改变它呢？这是我的确切情况。我在“TDD by example”中了解到，我什至不能只编写该函数，甚至不能直接调用它，因为我需要先对其进行测试。所以在一个简单的例子（一个文件）中：我怎样才能创建一个新文件？对此有何测试？
你可以写这样的测试，但你通常不需要。这不是那种会破坏并且也需要自动化的东西。简单的手动测试将显示您的连接字符串是否正确。您不会测试是否可以创建文件。您将测试是否可以创建正确的内容，可能通过将TextWriter 传递给写入的方法。在测试中，您将使用StringWriter，并测试内容是否正确。无需玩文件系统。
有道理。所以在这样的情况下，我应该简单地编写函数而不先测试？我不知道存在这种例外情况。

【解决方案2】：

考虑编写集成测试。与单元测试测试独立的逻辑片段不同，集成测试的作用是确保所有片段能够正确地相互通信。

您的集成测试将引用属性文件、启动和关闭您的服务，并通常确保您的所有活动部件都没有损坏。

有时，明智的做法是mock 组件。毕竟，您实际上并不是在测试组件，而是在测试它们运行的环境。

【讨论】：

“毕竟，你并没有真正测试组件”——这正是我困惑的地方。如果我需要对文件的实际更改进行系统调用，我该如何测试？我不能只是调用它，因为我必须先测试它。我希望我的问题很清楚。
你没有测试系统调用。它没有坏。测试调用系统调用的代码。你需要一种新的心态。