如何将TDD应用于读/写功能？

好像是鸡和鸡蛋的问题。

您可以使写入功能写入某些数据存储，但是在没有经过测试的读取功能的情况下，永远不会知道您是否正确保存了它。

您可以使读取功能从数据存储中读取，但是如何在没有经过测试的写入功能的情况下将东西放入该数据存储中以进行读取呢？

编辑：

我正在连接到SQL数据库并与之进行事务，以保存和加载要使用的对象。测试数据库提供的访问功能毫无意义，但是我包装了这些数据库功能以对对象进行序列化/反序列化。我想确保我正在正确地从数据库中写入和读取正确的内容。

它不像@snowman提到的添加/删除。我想知道我写的内容是正确的，但这需要经过良好测试的读取功能。当我阅读时，我想确保我的阅读正确地创建了一个与所写内容相等的对象。但这需要经过良好测试的写入功能。

从读取功能开始。

• 在测试设置中：创建数据库并添加测试数据。通过迁移脚本或从备份。由于这不是您的代码，因此不需要在TDD中进行测试

• 在测试中：实例化您的存储库，指向您的测试数据库，然后调用Read方法。检查是否返回测试数据。

现在，您具有经过全面测试的读取功能，可以转到写入功能，该功能可以使用现有的读取来验证其自身的结果

我经常只做写然后读。例如（伪代码）

Foo foo1 = setup some object to write
File tempfile = create a tempfile, possibly in memory 
writeFoo(foo1, tempfile) 
Foo foo2 = readFoo(tempfile) 
assertEquals(foo1, foo2); 
clean-up goes here

以后添加

除了该解决方案“实用”和“足够好”之外，还可以说其他解决方案测试了错误的东西。测试字符串或SQL语句是否匹配不是一个糟糕的主意，我自己做过，但是它正在测试副作用，而且很脆弱。如果您更改大小写，添加字段或更新数据中的版本号该怎么办？如果您的SQL驱动程序切换了调用顺序以提高效率，或者更新的XML序列化器增加了额外的空间或更改了架构版本，该怎么办？

现在，如果您必须严格遵守某些官方规范，那么我同意检查详细信息是适当的。

别。不要对I / O进行单元测试。这是浪费时间。

单元测试逻辑。如果要在I / O代码中测试很多逻辑，则应重构代码，以将I / O操作方式和I / O操作逻辑与实际的I / O业务分开。 （几乎无法测试）。

为了详细说明，如果要测试HTTP服务器，则应通过两种类型的测试进行测试：集成测试和单元测试。单元测试应该完全不与I / O交互。这很慢，并且引入了许多错误条件，这些错误条件与代码的正确性无关。单元测试不应受网络状态的限制！

您的代码应分开：

• 确定发送什么信息的逻辑
• 确定发送哪个字节以发送特定信息位（我如何将响应等编码为原始字节）的逻辑，以及
• 实际上将这些字节写入套接字的机制。

前两个涉及逻辑和决策，需要进行单元测试。最后一个不涉及做出许多决定（如果有的话），并且可以使用集成测试进行出色的测试。

实际上，通常这只是一个好的设计，但其原因之一是它使测试更容易。

这里有些例子：

• 如果要编写从关系数据库获取数据的代码，则可以进行单元测试，以将关系查询返回的数据映射到应用程序模型。
• 如果您正在编写将数据写入关系数据库的代码，则可以在不实际测试使用的特定SQL查询的情况下，对要写入数据库的数据进行单元测试。例如，您可以在内存中保留应用程序状态的两个副本：一个代表数据库外观的副本和一个工作副本。当您想同步到数据库时，您需要比较它们并将差异写入数据库。您可以轻松地对该差异代码进行单元测试。
• 如果要编写从配置文件中读取内容的代码，则要测试配置文件格式解析器，但要使用测试源文件中的字符串而不是磁盘中的字符串。

我不知道这是否是标准做法，但对我来说很好。

在我的非数据库读写方法实现我用我自己的类型特异性toString()和fromString()方法的实施详情。

这些可以很容易地单独测试：

 assertEquals("<xml><car type='porsche'>....", new Car("porsche").toString());

对于实际的读写方法，我有一个集成测试，可以在一个测试中进行物理读写

顺便说一句：拥有一个同时测试可读写的测试有什么问题吗？

已知数据必须以已知方式格式化。实现此目的最简单的方法是使用常量字符串并比较结果，如@ k3b所述。

但是，您不仅限于常量。您可以使用其他类型的解析器来提取书面数据的许多属性，例如正则表达式，甚至是寻找数据特征的临时探针。

至于读取或写入数据，拥有一个内存文件系统可能会很有用，该文件系统允许您运行测试而不会受到系统其他部分的干扰。如果您无权访问良好的内存文件系统，请使用临时目录树。

使用依赖注入和模拟。

您不想测试您的SQL驱动程序，也不想测试您的SQL数据库是否在线并正确设置。那将是集成测试或系统测试的一部分。您想测试代码是否发送了应该发送的SQL语句，以及是否以应有的方式解释了响应。

因此，当您有一个应该对数据库执行某些操作的方法/类时，请不要让它本身获得该数据库连接。对其进行更改，以便将代表数据库连接的对象传递给它。

在生产代码中，传递实际的数据库对象。

在单元测试中，传递一个模拟对象，该对象的行为就像实际的数据库实际上没有联系数据库服务器。只需检查它是否接收到了应该接收的SQL语句，然后以硬编码响应进行响应即可。

这样，您甚至不需要实际的数据库就可以测试数据库抽象层。

如果您使用的是对象关系映射器，则通常会有一个关联的库，该库可用于通过创建聚合，将其持久化并从新的会话中重新加载它，然后针对原始对象。

NHibernate提供持久性规范测试。可以将其配置为针对内存存储进行工作，以进行快速的单元测试。

如果遵循“存储库”和“工作单元”模式的最简单版本，并测试所有映射，则可以依靠几乎可以正常工作的东西。