让我描述一下场景:
我们的 VB.NET 网络应用程序通过网络服务与第三方数据提供者对话。它还将数据保存在一个巨大的 SQLServer 数据库中,该数据库在存储过程和触发器中实现了广泛的业务逻辑。 Web 服务提供商还采用了非常动态的复杂业务逻辑。
问题在于,web 服务提供商和 sqlserver 本质上都是实时系统,我们公司无法在正常操作(web 和 SQL 调用)之外访问它们。他们都没有提供有用的支持。
此外,网络服务没有“测试模式”,所有调用都被视为实时事务。不可能模仿这些系统中的任何一个的逻辑,也不可能获得 sqlserver 数据库的副本。
所以,我的问题是:
您如何针对这些实时系统对我们的 VB.NET 应用程序进行任何类型的测试(手动或自动)?
我们将不胜感激。
最佳答案
让我们首先挑战您的假设“不可能模仿这两个系统中的任何一个的逻辑”。
当然,如果您使用正确的工具,您可以模仿这种行为。您的系统通过数据库对象与数据库交互;您的系统应该通过 Web 服务对象与 Web 服务交互。这些对象中的一个或两个都可以是 mocked通过使用适当的模拟框架。对于对数据库对象的任何单元测试调用,您为该对象创建一个模拟,为调用设置它的期望和结果,然后将模拟交给您的被测代码 (CUT) 而不是“真实的”数据库对象。您的代码调用模拟,然后将其参数与预设期望进行比较,并返回预期结果(而不是实际与数据库通信)。然后您的代码对结果进行操作。如果方法参数与预期不匹配,模拟对象将抛出异常。
您可以在此处阅读有关 .Net 的模拟对象和单元测试的文章:
- Mock Objects to the Rescue! Test Your .NET Code with NMock
- How Typemock Isolator Simplifies Unit Testing
请注意,像 NMock 这样的工具和 Typemock使工作更容易,但它仍然很难——您需要设计要测试的代码,而不仅仅是先编写代码然后祈祷您可以稍后对其进行测试。
您可能想与您的网络服务提供商交谈——除了简单查询之外,我曾经与之交互过的每个第三方网络服务都有测试模式(您使用测试凭据和测试服务器,而不是实时服务器) .到测试服务器的任何事务都会在一天结束时得到清理。如果他们不提供测试服务并且他们的服务涉及的不仅仅是简单的查询,那么我强烈建议您寻找其他服务提供商。
在某些情况下,您可以采用另一种策略来处理数据库:使用事务。当您在单元测试期间打开数据库连接时,打开一个事务。在每个单元测试结束时,回滚事务。想法很简单,但是细节决定成败,一不小心把事务搞砸了就会乱。我不推荐它,但我在一个项目上这样工作了 2 年。
关于sql-server - 针对实时系统进行测试的策略,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1829135/