我有一个数据库密集型的应用程序。大多数应用程序方法都在更新数据库中的数据。有些调用是存储过程的包装，而其他调用是使用第三方API在代码中执行数据库更新。
我应该在单元测试中测试什么？我应该......
我最初的想法是＃2，但我担心的是我会写一堆框架代码来配合我的单元测试。我读到你不应该为单元测试编写一堆框架代码。
思想？
编辑：我的意思是框架是将大量其他代码用作单元测试代码的库 ...而不是第三方框架。
答案 0 :(得分：8)
我做2号，即通过更新记录测试更新，然后将其读回并验证值与您输入的值相同。在事务中执行更新和读取，然后回滚，以避免对数据库产生永久性影响。我不认为这是测试框架代码，我认为它不仅仅是测试操作系统代码或网络代码......框架（如果你的意思是非应用程序特定的数据库访问层组件）应该进行测试和验证独立地
答案 1 :(得分：3)
还有第三种选择，即使用模拟数据库访问对象，该对象知道如何响应更新，就像它已连接到实时数据库一样，但它并不真正对数据库执行查询。
此技术可用于补充针对实时数据库的测试。这与针对实时数据库进行测试不同，不应替代此类测试。但它至少可用于测试您的类调用数据库更新是否通过适当的输入完成。它通常比运行针对真实数据库的测试运行得快得多。
答案 2 :(得分：1)
您必须测试代码对数据的实际影响，以及它是否符合验证规则等，而不仅仅是没有引发异常 - 这有点像检查程序编译！
难以测试执行插入，更新或删除（DML）的数据库代码，因为测试会更改其运行的环境，即数据库。连续几次运行相同的过程可能（并且可能应该）每次都有不同的结果。这与单元测试“纯代码”非常不同，它可以运行数千次并且总是得到相同的结果 - 即“纯代码”是确定性，执行DML的数据库代码不是。< / p>
出于这个原因，您经常需要构建一个“框架”来支持数据库单元测试 - 即脚本在正确的状态下设置一些测试数据，并在测试运行后进行清理。
答案 3 :(得分：1)
如果您不是手动编写数据库而是使用框架（jvm，.net framework，...），则可以安全地假设框架正确地写入数据库。如果您正确使用框架，则必须测试的是什么。
只需模拟数据库方法和对象。测试您是否正在调用它们并正确检索数据。这样做将使您有机会更轻松地编写测试，更快地运行它们并使它们平行而不会出现任何问题。
答案 4 :(得分：1)
他们不应该单位进行测试！这些方法的重点是集成与外部世界（即数据库）。因此，请确保您的集成测试击败了您知道的那些方法并忘记了单元测试。
它们应该是如此简单以至于它们“显然没有错误”，无论如何 - 如果它们不是，你应该将它们分解成一个具有逻辑和愚蠢部分的部分，这些部分只需要一个价值并坚持它在数据库中。
请记住：目标是100％测试覆盖率，而不是100％单元测试覆盖率;其中包括所有测试：单元，集成，功能，系统，验收和手动。
答案 5 :(得分：0)
如果更新逻辑很复杂，那么你应该做＃2。
在实践中，真正单元测试复杂计算和更新的唯一方法 比如说，计算一组客户交易的银行费用， 是在一开始时将一组表初始化为已知值 单元测试并测试最终的预期值。
答案 6 :(得分：0)
我使用DBUnit使用数据加载数据库，执行update-logic并最终从数据库中读取更新的数据并进行验证。基本上是＃2。