在 asp.net mvc 中测试上下文答案

【问题标题】：Testing the context in asp.net mvc在 asp.net mvc 中测试上下文
【发布时间】：2010-03-31 11:44:53
【问题描述】：

我在测试控制器方面非常有经验，但我的问题是，我们是否也应该测试数据上下文，以及如何测试？我的意思是，有很多来自数据库的关系和约束，只是测试控制器没有涵盖。

另一方面，对 DB 进行测试并不被认为是一种好的做法——那又如何呢？只需在没有 db.SubmitChanges() 或什么的情况下进行测试？

【问题讨论】：

标签： asp.net-mvc unit-testing linq-to-sql datacontext

【解决方案1】：

恕我直言，您不应该测试 DataContext。希望微软已经做到了这一点，所以测试 SubmitChanges 将数据持久化到数据库中对我来说毫无意义。您应该在定义特定场景并验证应用程序输出的情况下进行集成或 Web 测试。

【讨论】：

【解决方案2】：

在测试存储库时，典型的方法是创建一个内存数据库，每次运行测试时都可以拆除和重建该数据库。通过使用这种方法，您将始终知道数据会是什么样子，因此您可以更轻松地对其进行断言。此外，您不会触及真实数据，这始终是积极的。 Sqlite 是 .NET 领域中最流行的。

【讨论】：

【解决方案3】：

是的，您应该对您的数据上下文进行集成测试，以确保您放入数据库本身的任何“代码”都能正常工作——唯一性约束、触发器等。这并不意味着但是，您应该对数据库进行单元测试。话虽如此，您放入模型类中的任何代码都应该进行单元测试。通常，您可以执行此操作而无需直接针对数据库进行测试。例如，任何验证代码都应该能够在不需要您实际插入或更新数据库的情况下运行。

【讨论】：

问题是我使用jQuery验证，因为系统事先不知道哪个属性有哪些验证。我正在通过管理面板添加自定义内容类型，并通过该管理面板为每个字段添加验证 => 在模型类中没有任何验证代码
我并不是在暗示您需要在模型中包含验证代码，只是将其用作模型中的代码示例，您应该对它进行单元测试（如果它在那里）并且不应该需要访问真实的数据库。