Тестирование интеграции SpecFlow с шаблонами базы данных

Question

Я пытаюсь настроить SpecFlow для интеграции/приемочного тестирования. Наш продукт имеет базу данных поддержки (не огромную, хотя) в Sqlite.

Это на самом деле оказывается слегка липкую точку, хотя; как я могу моделировать базу данных для тестов?

Я хотел бы знать, какие шаблоны других там использовать для выполнения интеграции/приемочных испытаний с базами данных отступающих.

я могу думать о следующих подходах:

1. Составьте базу данных в сборку с тестами, то теневым скопировать его для каждого теста. Кажется медленным.
2. Я мог бы создать базу данных в памяти и заполнить ее предварительно определенными данными.
3. Я мог бы создать базу данных в памяти и каким-то образом Givens заполнить базу данных. Похоже, что это надует тесты ужасно, но может дать им больше контроля и сделать тесты менее хрупкими.
4. Я мог бы абстрагировать каждое взаимодействие с базами данных и использовать mocks. Не любите эту идею, так как я хотел бы использовать ее для тестирования взаимодействия с базами данных.
5. Компиляция базы данных в тестах и ​​полагаться на очистке кода, чтобы вернуть его к базовому состоянию (это, кажется, хитроумный для меня). Не хотите делать это с транзакциями, так как будет несколько взаимодействий с некоторыми тестами (так что напишите элемент, затем попытайтесь прочитать его с разными привилегиями).

Answer 1

Перед рассмотрением Как, чтобы проверить, я думаю, вы могли бы найти это ценное, чтобы посмотреть на Что вы хотите проверить.

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

• Если вы работаете в системе здравоохранения, вы можете определить человека «Боб», а затем произвести его жизненные события. Боб родился 37 лет назад сегодня, упал с велосипеда в детстве, сломал ему руку, женился и двое детей.
• Если вы работаете в финансовой торговой системе, вы можете посмотреть день между открытием и закрытием для пары акций, например. «MSFT» и «APPL». В этот день вы можете увидеть один начальный минимум и лазание, а второй стартовый максимум и падение. Появляется новость, которая отменяет их состояние.

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

Одна вещь, на ваш вопрос, кажется, не нужно рассматривать как обновление данных. Например, вы можете захотеть иметь набор тестов, которые работают на разных этапах жизненного цикла ваших объектов, например. Некоторые тесты касаются «Бэби-Боба», другие - «10-летняя Боб» или «Женатый Боб» и т. Д.Если ваша БД только для чтения, то это не проблема, если вы можете написать свои тесты, чтобы они просто не см. другие данные, но иногда вы хотите создать историю через свои тесты. Если ваши тесты изменят данные, у вас возникнут проблемы с обеспечением того, чтобы либо ваши тесты выполнялись в порядке (см. MSTest OrderedTest, либо mbUnit DependsOn), либо вы можете отделить свои тесты, чтобы каждый из них имел дело с изолированным объектом данных (это нормально если ваш объект может быть описан в одной строке, но становится сложнее, когда вам нужно прочитать много таблиц, чтобы получить его).

Вы также можете рассмотреть какой код, который вы тестируете, вы можете изменить подход в своих разных наборах тестов. В настоящее время я работаю над многоуровневым приложением, которое имеет представления пользовательского интерфейса, модели для просмотра, модели клиентов, несколько систем связи и модели серверов. У меня также есть разные наборы тестов для них. У меня есть несколько тестов, которые работают в одном ярусе, издеваясь над другими уровнями, чтобы мои тесты были небольшими. Другие тесты запускают локальный сервер и локальный клиент и напрямую подключают их. Наконец, у меня есть некоторые тесты, которые запускают полный серверный процесс, обмениваются данными через EMS и запускают некоторые простые операции на стороне клиента, используя все, кроме UI Views.

Так что теперь на самом деле ответить на ваш вопрос,

1. теневую копию базы данных - Да, я сделал это один раз с SQLServer Developer и имел xxx.mdb, который получил скопированный в перед запуском тестов , Однако некоторые современные рамки тестирования будут проводить тесты параллельно, например. NCrunch, так что это просто ломается.
2. Создать базу данных и предварительно заполнить - Не было сделано это, но мои проблемы будут связаны с тем, что происходит, когда тест изменяет базу данных на непредвиденное состояние. Другие тесты потерпят неудачу, если они не сделали ничего плохого.
3. Создание базы данных и использовать Гивенс - Я сделал это с помощью NUnit [SetupFixture] на вершине Linq к Sql DB.You все еще есть сомнения по поводу параллельных тестовых прогонов, и вы должны сбалансировать детализацию ваших данности (см. StackOverflow-When do BDD scenarios become too specific), и у вас есть проблема с резервированием данных/изоляцией данных, но это может работать очень хорошо, чтобы вы могли работать с вашими историями данных и вырабатывать данные во время ваших тестов. С другой стороны, если один тест завершится неудачей и оставьте данные в плохом состоянии, у вас может получиться множество сбоев, но, по крайней мере, вам просто нужно посмотреть на то, что не удалось в первую очередь. Подобные тесты также не будут очень хороши для разработчиков на их рабочей станции, поскольку они не могут просто запускать один тест, особенно с такими инструментами, как NCrunch, которые могут просто запускать тесты, чей код изменился.
4. Макет базы данных Вот как я сейчас решаю. Хитрость заключается в том, что если вы лично следуете достаточно строгим процедурам TDD, где вы проверяете только тот метод, над которым работаете, то на самом деле вы получаете некоторые уровни, которые проверяют взаимодействие с базой данных, например. [Test]DALLayerTests.ShouldReadARowAndCreatePOCO(), но большинство других, которые использовали посмеянные данные для проверки того, что на самом деле происходит, например. [Test]BusinessObjectPersonTests.ShouldGetBirthdayCongratulations().
5. Используйте очистить код - Никогда не пробовал, это звучит Хитрая :-)