人们如何测试他们的业务应用程序？我看过很多“简单测试”例子的单元测试例子。防爆。一个计算器。人们如何测试数据量大的应用程序？你如何整理你的样本数据？在许多情况下，一项测试的数据可能根本无法用于另一项测试，这使得只有一个测试数据库变得困难。你如何测试业务应用程序？
测试代码的数据访问部分非常简单。它正在测试所有对付似乎难以测试的数据的方法。例如，想象一个发布过程，其中存在大量数据访问以确定发布内容，数字是否经过调整等。有多个临时步骤发生（并且需要测试）以及之后的测试，以确保发布是成功的。其中一些步骤可能实际上是存储过程。
在过去，我试过在测试数据库中插入测试数据，然后运行测试，但老实说写这种代码非常痛苦（并且容易出错）。我也试过只是先建立一个测试数据库并回滚这些更改。这很好，但在很多地方你也不能轻易做到这一点（许多人会说这是集成测试;所以，我仍然需要能够以某种方式测试）。
如果答案是没有一个很好的方式来处理这个问题，它目前只是一些糟糕的事情，这也是有用的知道。
任何想法，想法，建议或技巧值得赞赏。
当我尝试用回滚解决方案来处理这些集成测试时，我必须通过@Phil Bennett来发表评论。
我对集成测试数据访问层一个非常详细的岗位here
我不仅显示样本数据访问类，基础类和示例数据库的事务夹具类，而是一个完整的CRUD集成测试瓦特/示例数据显示。使用这种方法，您不需要多个测试数据库，因为您可以控制每个测试的数据，并且在测试完成后，所有事务都会回滚，因此您的数据库是干净的。因为如果你嘲笑你的业务对象拥有的所有依赖关系，那么测试你的应用程序逻辑变得非常简单，因为你可以在你的应用程序中测试一个实体，一次;）
编辑：那么你是否正在寻找一个巨大的集成测试，将验证从逻辑预数据库/存储过程运行瓦特/逻辑的一切，最后在回来的路上验证一切？如果是这样，你可以打破这个伸到2步：
1 - 单元测试数据推 到您的数据访问代码，在此之前发生的逻辑。对于 例如，如果你有一些代码， 计算基于 一些特性的一些数字 - 编写一个测试 只检查，看是否逻辑 这个1层的功能是什么，你问 做的事。在数据访问类中剔除任何依赖关系 ，因此您可以仅在 应用程序逻辑的此测试中忽略它。
2 - 集成测试，一旦你把你的 操纵数据（从测试的是上 方法，我们单位），并调用相应的 存储过程发生的逻辑。做 这里面的数据具体测试 类，所以你可以回滚之后它的 完成。您的存储 程序运行后，做一个查询 针对数据库现在让你 对象，我们也做了一些 逻辑对数据和验证 有你所期望的值 （存储后的程序逻辑的/ etc）
如果您需要在数据库中存储过程运行的项目，只需您在有里面的逻辑存储过程的前插入的数据。例如，如果您有需要测试的产品，则可能需要供应商和类别条目在插入产品之前插入，以便为供应商和类别执行快速而脏的插入操作，以便您的产品插入按计划工作。
对于许多不同的运行在相同的逻辑，但用不同的数据，只要你喜欢的输入和持续输出等
这取决于你在做什么，你可以使用CSV，多列测试。如果您正在测试业务逻辑组件 - 那么它在数据来自哪里并不重要，您可能会使用模拟或手动滚存类来模拟组件在野外会调用的数据访问例程。我唯一一次混淆数据访问的时候是我实际测试数据访问组件本身。
即使是这样我倾向于在TestFixtureSetUp方法打开一个数据库交易（显然这取决于你可能会使用什么样的单元测试框架），并在测试套件TestFixtureTeardown结束回滚事务。
听起来好像您可能正在测试基于消息的系统或具有高度参数化接口的系统，其中有大量输入数据的排列。
一般而言，所有标准unti测试的规则仍然成立：
一旦做到这一点，你会已经删除了很多复杂的自测试，希望是良好的结果集的单元测试，并简化样本数据。
然后编译样本数据以进行仍需要复杂输入数据的测试样本数据的一个好方法是Orthogonal testing或请参阅here。
我已经使用这种方法为WCF和BizTalk解决方案生成测试计划，其中输入消息的排列可以创建多个可能的执行路径。
模拟框架使您能够测试您的业务对象。 数据驱动的测试通常最终变得比单元测试更多的是一体化测试，他们还带着管理数据存储状态的负担，测试执行前后的数据存储状态以及连接和执行查询所花费的时间。
在一般情况下，我会避免做单元测试，从您的业务对象触摸数据库。至于测试你的数据库，你需要一个不同的策略。
这就是说，你永远不能完全摆脱数据驱动的测试，只能限制实际需要调用你的后端系统的测试数量。
我的自动化功能测试通常遵循两个patters之一：
数据库连接测试
当我自动化连接到数据库的测试，我通常会创建一个测试数据库模板有足够的数据用于所有测试。运行自动化测试时，将为每个测试生成一个新的测试数据库。测试数据库必须不断重新生成，因为测试通常会更改数据。在添加测试时，我通常会将更多数据附加到测试数据库模板。
这种测试方法有一些很好的优点。显而易见的好处是测试还可以锻炼你的模式。另一个优点是，在设置初始测试后，大多数新测试将能够重新使用现有的测试数据。这使得添加更多测试变得很容易。
缺点是测试数据库将变得笨拙。因为数据通常会随时添加一个测试，所以它会不一致，甚至可能不现实。当存在重要的数据库模式更改时（这对我来说通常意味着我最终会诅咒自己），您最终还会诅咒安装测试数据库的人员。
如果您无法随意生成新的测试数据库，则此类测试显然不起作用。
模拟持久层测试
对于这个模式，创建mock objects与测试用例生活。这些模拟对象拦截对数据库的调用，以便以编程方式提供适当的结果。基本上，当你测试的代码调用findCustomerByName()方法时，你的模拟对象被调用而不是持久层。
有关使用模拟对象测试的好处是，您可以获得非常具体的。通常，执行路径在无模拟对象的自动化测试中无法实现。他们还可以让您免于维护大量的整体测试数据。
另一个好处是缺乏外部依赖性。由于模拟对象模拟持久层，因此测试不再依赖于数据库。这通常是决定选择哪种模式时的决定性因素。模拟对象似乎在处理遗留数据库系统或具有严格许可条款的数据库时更具吸引力。
模拟对象的缺点是它们经常会导致大量额外的测试代码。这并不可怕，因为几乎任何数量的测试代码在运行测试的次数上分摊时都很便宜，但是如果有更多的测试代码，然后生产代码，可能会很烦人。
是的回滚策略在过去对我来说效果很好。 – tjjjohnson 2009-05-27 02:42:53