TDD：如何测试数据持久性抽象

Question

问题陈述

我想说我想实现一个简单的键值存储，它提供基本的CRUD操作。唯一的要求是所有修改应该在应用程序启动之间保持不变。我并不关心特定的持久性机制，因为它可能在开发过程中发生变化，甚至可能因平台而异。

问题

我应该如何处理这样的库/类/模块（最终到底哪个）？

我发现的所有答案都集中在测试特定的数据库解决方案，但那是我想要避免的。我只关心正在持续存在的事实，而不是关于 的持续存在。

我考虑过的解决方案：

• 提取实际的持久性实现，并分别测试每个实现，并仅测试抽象层是否调用正确的方法

我用这种方法看到的问题是用于非常简单的任务的大量代码，而且我最终仍然关注特定的持久性机制。这可能使开发复杂化，特别是对于键值存储这样简单的事情。

• 进行多次实际启动应用程序的测试，并检查数据更改是否在启动之间保持不变

这将测试我需要的确切内容，但这样的测试可能会很昂贵，并且不一定容易编写。

• 仅在方法适用于单个流程时才进行测试，不要测试持久性

好吧，图书馆的重点是测试持久性。比如，一些用户设置或游戏保存。测试它是否在内存中工作并不能测试真正的问题。

也许其他一些解决方案，我没有想到？

我已经在这里和其他网站上阅读了与持久性和TDD相关的大多数主题，但我所能找到的只关注特定的持久性机制。

有些相关，但没有涉及测试主题： How many levels of abstraction do I need in the data persistence layer?

Answer 1

持久层是应用程序的port。因此，您的方法应该是将适配器写入该端口，并使用集成测试来测试该适配器。

测试本身不需要多次旋转适配器 - 测试实际上持续存在的东西就是测试持久性机制本身，这不是你关注的问题。在某些时候，你必须假设事情有效，并且他们有自己的测试来确保这是正确的。在大多数情况下，典型的写入然后回读测试都可以。

一旦适配器存在，您可以使用几种技术来编写其他测试 - 当适配器是其他单元的协作者时模拟适配器，或者使用适配器的内存实现（使用合同测试来查看适配器） -memory实现与另一个实现相同。