使用[DeploymentItem]属性进行数据驱动测试会导致NHibernate发生OracleDataClientDriver错误(vstest.console.exe,Visual Studio 2013)

时间:2017-05-26 12:51:30

标签: oracle visual-studio visual-studio-2013 nhibernate vstest.console

我们有一些集成/单元测试来验证我们的NHibernate映射。我介绍了一些数据驱动的测试,它们利用测试方法上方的[DeploymentItem]属性来导入CSV文件。单元测试项目中的任何测试中仅存在此属性会导致所有NHibernate映射测试失败并显示以下消息:

Error Message:
   Initialization method UnitTests.SearchOrganizationTests.Setup threw exception. NHibernate.HibernateException: NHibernate.HibernateException: Could not create the driver from NHibernate.Driver.OracleDataClientDriver. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.NullReferenceException: Object reference not set to an instance of an object..
Stack Trace:
    at NHibernate.Driver.OracleDataClientDriver..ctor()
 --- End of inner exception stack trace ---
    at System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck)
   at System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
   at System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark)
   at System.Activator.CreateInstance(Type type, Boolean nonPublic)
   at System.Activator.CreateInstance(Type type)
   at NHibernate.Bytecode.ActivatorObjectsFactory.CreateInstance(Type type)
   at NHibernate.Connection.ConnectionProvider.ConfigureDriver(IDictionary`2 settings)
 --- End of inner exception stack trace ---
    at NHibernate.Connection.ConnectionProvider.ConfigureDriver(IDictionary`2 settings)
   at NHibernate.Connection.ConnectionProvider.Configure(IDictionary`2 settings)
   at NHibernate.Connection.ConnectionProviderFactory.NewConnectionProvider(IDictionary`2 settings)
   at NHibernate.Cfg.SettingsFactory.BuildSettings(IDictionary`2 properties)
   at NHibernate.Cfg.Configuration.BuildSettings()
   at NHibernate.Cfg.Configuration.BuildSessionFactory()
   at MyApplication.DataContext.get_SessionFactory()
   at MyApplication.DataContext.GetClassMetadata(Type type)
   at MyApplication.DataContext.GetClassMetadata[T]()
   at MyApplication.DataContext.GetTableName[T]()

无论是从命令行使用mstest.exe还是vstest.console.exe,我都会遇到同样的错误。

从"测试资源管理器"运行测试在Visual Studio 2013中工作得很好。从命令行运行测试失败,这对我们的持续集成服务器来说是一个问题。

所以附加信息:

  • 它是Visual Studio中的单元测试项目
  • Oracle.DataAccess.dll文件位于构建输出目录中("复制本地"设置为" True")仅当我不运行用{修饰的测试时{1}}属性
  • 当运行至少1个使用[DeploymentItem]属性修饰的测试时,[DeploymentItem]文件不会被复制到输出目录
  • "复制到输出"所有CSV文件的属性都设置为"始终"
  • Visual Studio 2013
  • NHibernate版本4.0.4.4000
  • .NET 4.5.1
  • FluentNHibernate版本2.0.3.0
  • Oracle客户端12c安装在我的计算机上(12.1.0)

更新#1:我查看了Oracle.DataAccess.dll目录,但我没有看到Oracle.DataAccess.dll文件

更新#2:我们有一个测试,可以直接使用Oracle客户端库打开与Oracle数据库的连接。我在引用Oracle.DataAccess.dll文件的测试之上添加了一个[DeploymentItem]属性。现在NHibernate映射测试正在通过,但数据驱动的测试没有加载CSV文件。

TestResults/<Test run name>/Out

示例数据驱动测试:

[TestClass]
public class OracleConnectionTests
{
    [TestMethod]
    [TestProperty("Data Mappings", "Connection Test")]
    [DeploymentItem(@"..\Dependencies\Oracle.DataAccess.dll")]
    public void CanOpenCloseConnection()
    {
        OracleConnection oraConn = new OracleConnection("connection string here");
        oraConn.Open();
        Assert.IsTrue(oraConn.State == ConnectionState.Open);
        oraConn.Close();
        Assert.IsFalse(oraConn.State == ConnectionState.Open);
    }
}

如何包含[DeploymentItem]属性以允许数据驱动的测试加载CSV文件,并允许NHibernate在从命令行运行测试时加载Oracle驱动程序?

1 个答案:

答案 0 :(得分:0)

我最终用编译器标志“修复”了这个:

    [TestMethod]
    [TestProperty("PaginationPrologue", "Prologue remains fixed when nearing end of result set")]
    [DataSource(DATA_PROVIDER, DATA_FILE_PATH, DATA_TABLE_NAME, DataAccessMethod.Sequential)]
#IF DEPLOY_TEST_DATA
    [DeploymentItem(DATA_FILE_PATH, DATA_OUTPUT_PATH)]
#ENDIF
    public void WhenNearingEndOfResultSet_EpilogueIsNotIncluded()
    {
        Assert.AreEqual(data.EpilogueLength, epilogue.Count());
    }

由于此错误仅在我们的构建服务器上运行自动化测试时发生,因此这是一个足够好的修复程序。老实说,我仍然不确定为什么这有效,我只知道它确实有效。 3年多了,情况还算稳定。