Как автоматические приемочные испытания используют начальное состояние?

Question

Я разрабатываю приемочный тест для веб-службы. Тесты запускаются через Specflow и используют SQL Server CE как базу данных. Служба разделяет БД с другими приложениями и модулями и использует некоторые данные, созданные через одно из этих приложений.

С точки зрения моего продукта, есть два типа «данные»:

1. Данные, которые мы только потребляем
2. Данные, которые мы создаем/изменить

Перед запуском в тестовом примере вы настроили начальное состояние базы данных. Для только потребляемых данных единственный способ инициализации данных - вставка непосредственно в базу данных. Но для управляемых данных мы либо можем установить состояние непосредственно в БД, либо сделать это, как пользователь, сделав это, вызвав API.

Например, я хочу проверить, что мой метод 'updateItem' корректно обновляет цену элемента до 'y'. Чтобы выполнить этот метод, мне нужно настроить мою базу данных с помощью начального элемента с ценой «x». Есть два способа сделать это:

1. Установить состояние элемента непосредственно в базе данных
2. Вызова «CreateItem»

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

С другой стороны, со вторым методом плюсы и минусы были бы противоположными. Тест может потерпеть неудачу, потому что «createItem» потерпел неудачу, хотя некоторые тестовые среды скажут вам, что это было настроено на то, что не удалось, а не на фактический тест. Но независимо от того, какие изменения происходят в 'createItem', эти изменения автоматически включаются в ваш тест, и вам не нужно обновлять исходное состояние вручную.

Любые советы очень ценятся.

Answer 1

Чтобы быть справедливым, вы почти наверняка прикрепили свои непосредственные проблемы в вопросе, вам действительно нужно принять ваше решение.

Существует множество способов создания этих данных, больше, чем вы упоминали, и хотя этот вопрос не является дубликатом SpecFlow Integration Testing with Database Patterns, попробуйте в кратчайшие сроки взглянуть на это.

Хорошо, теперь нужно выбрать, лучше ли использовать существующий API, или нет? Ну, если нет, что делать? Я предполагаю, что вы собираетесь написать несколько дополнительных операторов SQL и вызвать их напрямую.

Не означает ли это, что вы создали другой API? У вас есть внешний API, который устанавливает цену на Y, и ваш новый внутренний/тестовый API, который устанавливает цену на X. Таким образом, вы удвоили код, который вам нужно написать и сохранить. Хуже того, есть вероятность, что быстрый и грязный код для тестов на самом деле будет скопирован и вставлен повсюду на всех ваших тестах, поэтому, когда он сломается, вам придется исправить его во многих местах.

Если вы можете, прекратите думать о базах данных. Think APIs. Вы упомянули, что у вас есть статические данные, которые просто должны быть на месте для тестов, поэтому соедините API для этого, неважно, не является ли оно общедоступным или используется только вашим приложением.Получите этот API на месте.

Затем замените то, что находится за API. Используйте Mocks, используйте представление в памяти, NoSQL db, XML-файл или все, что вам нужно, чтобы пройти этот индивидуальный тест, потому что со временем вы будете тратить столько времени на то, чтобы поддерживать эту БД. По мере того, как ваши тесты увеличивают его скорость, вы становитесь медленнее очень быстро, и, честно говоря, вы, как разработчик приложения, не заботитесь о, если SQL CE является лучшим решением. Когда системный архитектор (даже если это вы с другой шляпой), то приходит сказать, что нам нужно выйти из этой технологии и перейти к чему-то еще, по крайней мере, вы не привязаны к ней.

Answer 2

Ответ Алски хороший, но я думаю, что есть что-то еще, что вы должны учитывать. Хотя вызов API вашего приложения для создания вашего товара в порядке, вам следует опасаться долгосрочных последствий этого подхода, поскольку он может сделать ваши тесты значительно длиннее, чем нужно. Если все, что вы делаете, вызывает CreateItem, тогда все в порядке, но представьте, как ваше приложение растет с трудом, если вам нужно постоянно следить за рабочим процессом пользователей, вы можете сделать значительное количество шагов, чтобы получить данных в желаемом состоянии. Если вам необходимо проверить, что элементы, которые на складе отображаются на странице переупорядочивания, то вам может понадобиться, чтобы сделать все эти:

• CreateUser
• CreateProduct
• SetProductStockLevel
• CreateOrderForAllStock
• ShipOrder

Просто убедитесь, что ваш продукт существует и его нет в наличии. Это может занять значительное количество времени (особенно если ваши тесты основаны на селене).

Если вы только что ввели правильные данные в таблицы в первую очередь, это будет работать намного быстрее.

Является ли это проблемой для вас, я не могу сказать, но помните об этом, прежде чем принимать решение.

К счастью, specflow меняет свое мнение об этом довольно легко. Ютов есть шаг, который является чем-то вроде

Given all the stock for <Product> has been sold 

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