Тестирование пользовательского интерфейса с RavenDB
Немного предыстории:
У меня есть веб-приложение, которое читает из денормализованного набора документов, хранящихся в RavenDB. Эти документы создаются и изменяются обработчиками событий. В работе приложение использует стандартное хранилище документов, которое подключается к удаленной базе данных через API C#.
Когда я тестирую приложение, я настраиваю обработчики для использования встроенной базы данных в памяти, создания некоторых событий и запроса ожидаемых документов. Это работает абсолютно нормально.
Написание тестов пользовательского интерфейса:
Я хочу, чтобы наши тестировщики могли писать автоматизированные тесты пользовательского интерфейса, используя SpecFlow и Selenium. При реализации этого для других приложений (с использованием SQL) выполнение файлов компонентов подготовит среду тестирования путем:
- Создание новой базы данных в локальном экземпляре SQLExpress (по договоренности у всех одинаковое имя экземпляра на своих машинах)
- Переконфигурируйте обработчики для использования новой базы данных и создания событий для создания желаемого состояния.
- Скопируйте тестируемое веб-приложение в новое временное местоположение и перенастройте его для чтения из новой базы данных.
- Запустите веб-приложение в IIS Express (еще раз все следуют этому соглашению)
- Запустите функцию (и), отключив и восстановив состояние между ними, если это необходимо
- Остановите IIS, удалите тестируемое приложение и удалите базу данных.
Теперь я хотел бы придерживаться того же подхода с использованием Raven, и я рассматриваю два подхода.
Первое - следовать той же модели, что и выше. У меня есть следующие вопросы: как / где хранить базы данных и как их убирать. Исполняемый файл сервера может быть запущен и остановлен программно во время установки и демонтажа, а база данных может быть впоследствии удалена путем удаления файла. Я не пробовал это, но в теории это должно работать.
Второе - следовать аналогичному подходу, но заменить стандартное хранилище документов на встроенное (не работающее в памяти). Чтобы это работало, мне нужно изменить IoC (возможно, если использовать config в xml) веб-приложения, чтобы преобразовать IDocumentStore в EmbeddedDocumentStore. Затем я создаю состояние с использованием обработчиков, как и раньше, а затем избавляюсь от хранилища документов обработчиков перед запуском IIS (кажется, что невозможно запустить два приложения одновременно, использующих одну и ту же встроенную базу данных, если я не пропущу) что-то).
Второй подход сначала казался лучшим выбором, но я сталкиваюсь со странным поведением, когда документы, созданные обработчиками, не соответствуют результатам, возвращаемым при запросе веб-приложением. В частности, некоторые дочерние коллекции заполняются обработчиками, но они пусты при возврате из запроса, выполненного веб-приложением. Честно говоря, я не был слишком удивлен, поскольку сомневаюсь, что это сценарий, в котором встроенные базы данных были предназначены для использования. Кроме того, очень сложно просматривать встроенную базу данных через студию управления, когда я перехожу из одного приложения в другое.
Так или иначе, после этого длинного подробного описания мне любопытно, что другие думают об этих подходах, и если есть лучшая альтернатива, я пропускаю. Кроме того, я уверен, что есть много скрытых драгоценных камней RavenDB, о которых я не знаю, поэтому любые указатели в этом направлении также будут полезны.
1 ответ
Найджел, Старт / Стоп raven.server программно. Но передать /ram флаг, который позволит вам запустить все это в памяти и может позаботиться обо всей работе по очистке