сервисный уровень модульного тестирования - NUnit, NHibernate

Question

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

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

для создания схемы БД. После этого я заполняю некоторые таблицы поиска из некоторых таблиц Excel.

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

Christian

Answer 1

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

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

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 antipattern, что означает, что каждый тестовый случай должен начинаться с пустой базы данных и сам заполнять соответствующие строки, используя Back Door Manipulation .

Я уже несколько раз писал о своем опыте тестирования на базах данных .