WCF/SQL Server的集成测试太慢?

问题描述:

但是,通过查看数据库来验证结果,表明在此测试的系统实际上是成功的,所以我有一个集成测试(在Visual Studio中)保持失败。WCF/SQL Server的集成测试太慢?

这是测试的基本思想:

private static readonly EfContext db = new EfContext(); 

[TestMethod] 
void Complete_System_Run_Through_Is_Successful() 
{ 
    // Create a new unique message and request... 
    var message = Guid.NewGuid().ToString(); 
    var request = new FooRequest { Message = message }; 

    var fooClient = null; /* WCF proxy */ 
    try 
    { 
     // Call the service... 
     fooClient = new FooClient(); 
     fooClient.CallService(fooRequest); 
    } 
    finally 
    { 
     // Close client or Abort faulted client... 
     var channel = fooClient as ICommunicationObject; 
     try 
     { 
      if (channel.State != CommunicationState.Faulted) 
       channel.Close(); 
     } 
     catch { channel.Abort(); } 
    } 

    // Verify there are 15 instances (traces) present in the database... 
    var actualNumberOfTraces = db.Traces.Count(x => x.Message == message); 
    Assert.AreEqual(15, actualNumberOfTraces); 
} 

被测试的WCF服务触发一堆其他下游服务(认为“服务总线”),其中每个监听服务添加一个条目(迹)到数据库。从开始到结束,这个过程记录了每个完整系统运行的15个这些跟踪。

验证数据库中的结果表明测试运行成功(数据库中存在所有15条曲线)。但是,测试运行失败(在Visual Studio中),实际发现的痕迹数量在3-6之间。我唯一能想到的是,Assert被称为太早(即数据库尚未完成更新)。

无论如何,一切工作正常,所有的痕迹确实存在于数据库中,我只是有这个测试的麻烦。有什么建议么?

+0

如果没有catch(包含Assert.Fail,如果这是异常情况下需要什么)?或者wcf代理的使用块('fooclient'),我会建议不要尝试{...} finally {} 。有什么可以移动到您的测试启动或测试清理方法吗? – Chris

+0

我已经更新了代码示例以包含关闭/中止逻辑。这是关闭/中止WCF代理的首选方式,而不是使用语句。基本上,try/finally块在那里处理关闭/中止,而不是例外。 – Didaxis

+0

我会在外面尝试一个catch块。 – Paparazzi

看起来你有一个异步方法调用。本文介绍WCF同步和异步行为。

How to Call WCF Services Synchronously and Asynchronously

+0

这是异步的,因为这些服务使用MSMQ绑定/(单向操作)。真的,我只是想弄清楚这个测试是否会实际通过*。由于这些不连贯的服务的性质,我开始认为它不会。 – Didaxis

+1

与异步,你不应该期望它通过,所以我只是不明白它是如何增加任何价值。我认为你需要一种不同的方法来测试这个。 – Paparazzi

那么暂且丑陋的解决办法是增加一个Thread.Sleep(250)给数据库的时间来追赶。如果你能想出更优雅的解决方案,我绝对有兴趣听到它!

+0

一个更好的方法是等待,然后在循环中多次尝试断言,只要你认为合理(比如最大30秒)即可。在代码中放置不休息让测试不确定,并且在不同的spec机器上会失败。 – Paolo

+0

这是一个好主意,你可以发表一个如何做Task []的例子,WaitAll()在你正在谈论的循环中调用Assert?快点让我开始? – Didaxis