единичный тестовый сервисный уровень - NUnit, NHibernate

Question

Я хотел бы выполнить тестирование тестового уровня DEPENDENT, который позволяет мне выполнять операцию CRUD без издевательств с использованием NUnit. Я знаю, что это, вероятно, плохая практика, но я хочу попробовать в любом случае - даже если тесты должны проходить в течение ночи. Мои данные сохраняются с использованием NHibernate, и я реализовал небольшую библиотеку, которая «загружает» базу данных, которую я мог бы использовать в методе [Setup]. Мне просто интересно, сделал ли кто-то что-то подобное и какой самый быстрый способ для загрузки базы данных. Я использую что-то вроде этого:

var cfg = new Configuration(); 
      cfg.Configure(); 
      cfg.AddAssembly("Bla"); 
      new SchemaExport(cfg).Execute(false, true, false); 

, чтобы установить схему db. После этого я заполняю некоторые таблицы поиска из некоторых таблиц Excel.

Любая обратная связь будет очень признательна. Благодарю.

Christian

Answer 1

Ayende имеет хороший пример такого подхода в этом blog post. Его пример показан ниже с моими комментариями.

Поскольку Конфигурация является дорогостоящей для создания, она создается только один раз для каждого тестового прогона. Используется база данных SQLite in-memory, так как это самый быстрый способ выполнения запросов.

public class InMemoryDatabaseTest : IDisposable 
{ 
    private static Configuration Configuration; 
    private static ISessionFactory SessionFactory; 
    protected ISession session; 

    public InMemoryDatabaseTest(Assembly assemblyContainingMapping) 
    { 
     if (Configuration == null) 
     { 
      Configuration = new Configuration() 
       .SetProperty(Environment.ReleaseConnections,"on_close") 
       .SetProperty(Environment.Dialect, typeof (SQLiteDialect).AssemblyQualifiedName) 
       .SetProperty(Environment.ConnectionDriver, typeof(SQLite20Driver).AssemblyQualifiedName) 
       .SetProperty(Environment.ConnectionString, "data source=:memory:") 
       .SetProperty(Environment.ProxyFactoryFactoryClass, typeof (ProxyFactoryFactory).AssemblyQualifiedName) 
       .AddAssembly(assemblyContainingMapping); 

      SessionFactory = Configuration.BuildSessionFactory(); 
     } 

     session = SessionFactory.OpenSession(); 

     new SchemaExport(Configuration).Execute(true, true, false, true, session.Connection, Console.Out); 
    } 

    public void Dispose() 
    { 
     session.Dispose(); 
    } 
} 

При использовании этого испытания каждое испытание начинается с создания необходимых данных.

public class BlogTestFixture : InMemoryDatabaseTest 
{ 
    public BlogTestFixture() : base(typeof(Blog).Assembly) 
    { 
    } 

    [Fact] 
    public void CanSaveAndLoadBlog() 
    { 
     object id; 

     using (var tx = session.BeginTransaction()) 
     { 
      id = session.Save(new Blog 
      { 
       AllowsComments = true, 
       CreatedAt = new DateTime(2000,1,1), 
       Subtitle = "Hello", 
       Title = "World", 
      }); 

      tx.Commit(); 
     } 

     session.Clear(); 


     using (var tx = session.BeginTransaction()) 
     { 
      var blog = session.Get<Blog>(id); 

      Assert.Equal(new DateTime(2000, 1, 1), blog.CreatedAt); 
      Assert.Equal("Hello", blog.Subtitle); 
      Assert.Equal("World", blog.Title); 
      Assert.True(blog.AllowsComments); 

      tx.Commit(); 
     } 
    } 
} 

Answer 2

При написании таких Интеграция тестов, самые важные вещи, чтобы иметь в виду, что вы должны еще

• автоматизируют как можно больше (желательно все), который включает в себя установку и удалите его снова после использования
• избегайте антипаттерна General Fixture, что означает, что каждый тестовый пример должен начинаться с пустой базы данных, а i заполнить соответствующие строки, используя Back Door Manipulation.

Несколько раз в прошлом я писал около my own experiences with testing against databases.