Интеграционное тестирование в .net с nhibernate

Question

Я делаю несколько честных с Богом TDD для своего последнего проекта, и мне это нравится, я уже провела модульное тестирование, но не серьезный TDD, я считаю это полезным.

Некоторые сведения о моем проекте:

• ASP.Net Front End-
• NHibernate для взаимодействия баз данных с SQL Server 2008 express-
• C # 4.0 DLL для DOmain Logic и модульных тестов, которые выполняются в NUnit и проходят через resharper.
• Сервер Teamcity CI, выполняющий скрипт сборки NAnt.

Сейчас я нахожусь в «альфа-версии» и обнаружил, что все ошибки - это ошибки интеграции, в основном потому, что мое интеграционное тестирование было связано с использованием сайта вручную, и некоторыми незначительными автоматизированными действиями (которые я остановил) Бег). Это довольно плохо, учитывая, насколько строго я вырастил свой набор тестов, и я хочу исправить его.

У меня вопрос, как лучше всего проводить интеграционные тесты, или есть какие-нибудь статьи, которые я могу прочитать. Я понимаю, что тестирование пользовательского интерфейса будет проблемой в веб-формах ASP.NET (в будущем мы перейдем к более тестируемой среде, но по одному шагу за раз). Но я хочу убедиться, что мои взаимодействия с Hibernate проверены правильно.

Поэтому мне нужно несколько советов по интеграционному тестированию в отношении

• Nhibernate (кэширование, сессии и т. Д.) -
• Тестовые данные, я обнаружил, что 'NDBUnit' - это то, на что я должен обратить внимание, чтобы получить мои данные в хорошем состоянии? Это совместимо с NHibernate?
• Должен ли я заменить базу данных на SQLite или что-то еще? Или просто настроить другую базу данных SQL-сервера, которая содержит только тестовые данные?
• Как я могу сделать эти тесты ремонтопригодными? У меня было несколько интеграционных тестов, но они доставили мне неприятности и я избегал их. Я думаю, что это было главным образом из-за того, что я не устанавливал согласованное состояние каждый раз

Просто несколько общих советов было бы замечательно, я читал TDD на примере Кента Бека и «Искусство модульного тестирования» Роя Ошерова, и они отлично подходили для модульного тестирования / тдд, но я хотел бы прочитать немного больше о интеграционные тесты и стратегии их написания (что нужно тестировать и т. д.) ---

Answer 1

По части базы данных:
- Вы можете использовать его прямо в соответствии с положениями этой статьи: Модульное тестирование со встроенной поддержкой NHibernate .
- Использование SQLite для ускорения тестов также может быть очень полезным. Только в этом случае вы должны знать, что вы больше не ориентируетесь на реальную производственную конфигурацию.
- SQLite поддерживает не все функции, которые поддерживает SQL Server. В этой статье приведен пример кода для необходимой настройки теста для перехода на SQLite - это довольно просто и понятно.
- NDbUnit как механизм для подготовки тестовых данных также является хорошим выбором - если вы не ожидаете частых изменений схемы на вашей базе данных (в этом случае становится достаточно много работы для поддержания всех связанных с ними XML файлы ...).
По части ASP.NET:
- Вы можете найти такой инструмент, как Selenium , полезный для тестов на основе пользовательского интерфейса.

НТН!
Томас

Answer 2

Немного опоздал на вечеринку, но это то, чем я занимался некоторое время.

Я пишу API REST, которые должны использоваться нашими мобильными приложениями.Мобильные приложения также написаны на C #, поэтому для меня имеет смысл написать обертку API (SDK).

При тестировании интеграции я настраиваю тестовые случаи, которые проверяют все конечные точки API, используя SDK .При выполнении тестов API работает на моем локальном IIS в режиме разработки.Каждый раз, когда сервер запускается, моя база данных dev стирается, воссоздается и заполняется данными для всех таблиц , что дает мне несколько реалистичный сценарий.Мне также не нужно беспокоиться о тестировании обновлений / удалений, потому что все, что требуется, это перестроить серверный проект, и NHibernate отбросит, создаст и заполнит мою базу данных.При желании это можно изменить для каждого запроса.

При тестировании моих репозиториев для меня важно знать, могут ли мои запросы переводиться с помощью NHibernate, поэтому все мои тесты репозитория используют LocalDB, который воссоздается для каждого теста .Это означает, что в каждом тестовом примере можно установить необходимые начальные данные для успешного выполнения тестов запроса.

Другое дело, что при заполнении базы данных реалистичными данными вы также бесплатно тестируете настройки внешнего ключа.Кроме того, сеялка использует классы вашего домена, так что это тоже хорошо выглядит!

Пример сеялки:

public void Seed(ISession s) 
{
  using(var tx = s.BeginTransaction() 
  {
    var account1 = new Account { FirstName = "Bob", LastName = "Smith" };
    var account2 = new Account { FirstName = "John", LastName = "Doe" };
    account1.AddFriend(account2); // manipulates a friends collection
    s.Save(account1);
  }
}

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

Важно: настройка выполняется с помощью контейнера IoC.

Answer 3

Короткий ответ: не делайте интеграционных тестов.

У нас есть следующие настройки:

• Наши юнит-тесты тестируют как можно меньше. Мы тестируем только одну функцию бизнес-кода (не напрямую метод, а скорее логическую часть функциональности);

• Напишите модульный тест для каждой функции вашего бизнес-кода;

• Напишите модульный тест для взаимодействия между различными функциями вашего бизнес-кода;

• Убедитесь, что эти тесты охватывают все.

Это даст вам набор юнит-тестов, которые охватывают все.

У нас есть интеграционные тесты, но они написаны в документах Word и часто являются только оригинальными спецификациями. Специалист по тестированию запускает их, когда код доставляется, и в большинстве случаев он просто работает, потому что мы уже протестировали каждый маленький кусочек.

В InfoQ есть потрясающая презентация, которая очень хорошо объясняет этот способ работы: Интеграционные тесты - афера .

Одна вещь о тестировании NHibernate. Мы применили шаблон хранилища . Это означает, что наши запросы NHibernate становятся очень очень простыми, например:

public class NhRepository<T> : IRepository<T>
{
    public T Get(int id)
    {
        return GetSession().Get<T>(id);
    }
}

public interface IUserRepository : IRepository<User>
{
    IEnumerable<User> GetActiveUsers();
}

public class UserRepository : NhRepository<User>, IUserRepository
{
    public IEnumerable<User> GetActiveUsers()
    {
        return
            from user in GetSession().Users
            where user.IsActive
            return user;
    }
}

Это в сочетании с Windsor IoC-контейнером обеспечивает доступ к нашим данным. С этой настройкой дело в том, что:

1. Запросы невероятно просты (в любом случае, 98%), и мы не проверяем их полностью. Это может показаться странным, но мы склонны проверять их больше, используя рецензирование, чем любой другой механизм;

2. Эти репозитории могут быть легко смоделированы. Это означает, что для вышеупомянутого репозитория у нас есть макет, который делает что-то вроде этого:

   var repositoryMock = mocks.StrictMock<IUserRepository>();
   
   var activeUsers = new List<User>();
   
   for (int i = 0; i < 10; i++)
   {
       var user = UserMocks.CreateUser();
       user.IsActive = true;
       activeUsers.Add(user);
   }
   
   Expect.Call(repositoryMock.GetActiveUsers()).Return(activeUsers);
   

   Фактический код намного более лаконичен, но вы поняли идею.