如何使用公开API和与数据库对话的应用程序来实践高效的TDD？

Question

我倾向于编写许多应用程序，比方说，这些应用程序会将API公开给一个逻辑，该逻辑将调用同一逻辑中的其他API，然后将某种形式的数据保存到数据库的末尾。因此，换句话说，我倾向于有一个方法调用，封装调用其他API，处理数据，然后持久化到数据库。

我熟悉TDD (测试驱动开发)，但我发现很难实践，因为我最不想要的是在运行强制测试的同时将无用的数据保存在生产数据库中，同时调用外部API，而我不控制这些API，并反过来破坏它们的数据库。

我可能看错了。

我如何实践有效的TDD和回避这个问题？

Answer 1

我如何实践有效的TDD并回避这个问题？

设计。

粗略地说，我们排列我们的代码，以便它是由两种类型的模块组成的。

• 模块，易于测试的
• 模块，简单而稳定的

因此，实际需要与数据库对话的代码应该是第二种类型；没有分支，操作繁琐，最重要的是，它不需要经常更改。

我们编写的代码有内在的风险吗？这进入了一个“易于测试”的模块。这些模块只是松散地耦合到它们更简单的同类--应该很容易将“测试”实现替换为“真正的”实现。因此，我们没有在测试期间与“数据库”对话，而是在内存集合中与一些只提供脚本响应的内存集合进行交谈。

简而言之，我们安排代码是为了便于测试错误所在。

至于测试比特的难度；嗯，也许我们以其他方式度量风险，或者我们以不同的节奏运行这些测试，或者我们将它们的测试推迟到功能测试，或者.