集成测试通过NUnit Gui / Console失败,但在IDE中通过TestDriven

时间:2009-11-20 03:59:47

标签: oracle nhibernate nunit testdriven.net

我使用NHibernate.Driver.OracleDataClientDriver驱动程序类对Oracle数据库使用NHibernate。我有一个集成测试,当使用TestDriven.net通过IDE执行时,可以正确地回收预期的数据。但是,当我通过NUnit GUI或Console运行单元测试时,NHibernate会抛出一个异常,说它无法找到Oracle.DataAccess程序集。显然,这使我无法在我的CI过程中运行集成测试。

  

NHibernate.HibernateException:The   IDbCommand和IDbConnection   在程序集中实现   找不到Oracle.DataAccess。   确保装配   Oracle.DataAccess位于   应用程序目录或全局   程序集缓存。如果组件在   GAC,使用   应用程序中的元素   配置文件指定完整   程序集的名称。*

我尝试通过两种方式使程序集可用,方法是将其复制到bin \ debug文件夹中,并在配置文件中添加元素。同样,这两种方法在IDE中通过TestDriven执行时都有效。通过NUnit GUI / Console执行时都不起作用。

NUnit Gui日志显示以下消息。

  

21:42:26,377错误[TestRunnerThread]   ReflectHelper [(null)] - 无法加载   类型   Oracle.DataAccess.Client.OracleConnection,   Oracle.DataAccess。   System.BadImageFormatException:可以   不加载文件或程序集   “Oracle.DataAccess,   版本= 2.111.7.20,文化=中立,   PublicKeyToken = 89b483f429c47342'或   其中一个依赖项。一次尝试   是用来加载程序的   格式不正确。

     

文件名:'Oracle.DataAccess,   版本= 2.111.7.20,文化=中立,   PublicKeyToken = 89b483f429c47342'--->   System.BadImageFormatException:可以   不加载文件或程序集   'Oracle.DataAccess'或其中一个   依赖。试图做到   加载程序不正确   格式。

     

文件名:'Oracle.DataAccess'

我在Windows 7 64bit上运行NUnit 2.4.8,TestDriven.net 2.24和VS2008sp1。 Oracle Data Provider v2.111.7.20,NHibernate v2.1.0.4。

有没有人遇到过这个问题,更好的是,修好了吗?


狡猾,谢谢你的回复。但是,NUnit测试运行器使用正确的配置文件,因为我通过从预期的配置文件中提取已知值来进行测试。

我假设这与我的配置有关,特别是与Windows 7或64位版本有关。我继续在构建服务器(W2k3服务器)上安装/配置了Oracle客户端。我将测试移到了构建服务器上并运行了上述相同的场景,测试在所有情况下都按预期工作。

我通过在其他两个开发人员工作站(具有相同工具集版本的Win XP 32位)上运行场景来跟踪这一点,并且测试在所有情况下都按预期工作。

我很困惑但现在很满意。我可以通过IDE运行集成测试,并可以通过CI自动化在构建服务器上执行它们。现在唯一的问题是我无法在开发工作站上测试自动化构建项目。

3 个答案:

答案 0 :(得分:2)

当我尝试运行使用Oracle.DataAccess.dll(odp.net版本2.111.7.20)的应用程序时,我收到此错误。我在应用程序旁边运送了oracle 11g即时客户端。在64位服务器上它会失败。但是,我运送的客户端程序集是32位所以我编译了一个版本的应用程序,CPU标志设置为32位,现在它工作正常。这是因为当您告诉应用程序显式为32位时,服务器会在wow64模拟器中运行整个组件。

答案 1 :(得分:0)

配置NHibernate时遇到了类似的问题。问题是大多数测试跑步者都在使用与你的测试dll一起放置的app.config。但是某些版本的NUnit却没有。这就是为什么您的系统保持未配置状态的测试。您可以尝试从测试中手动配置NHibernate。希望它有所帮助

答案 2 :(得分:0)

通过进入测试项目的构建设置并将平台目标从“any cpu”更改为“x86”,我可能刚刚在本地计算机上解决了类似/相同的问题