У меня был разговор с кем-то о модульном / интеграционном тестировании с веб-приложениями, и у меня есть разногласия по поводу одной основной идеи. Проблема в том, что человек, с которым я разговариваю, думает, что база данных, от которой отработан модульный тест, должна иметь предварительно заполненные данные, и я думаю, что она должна быть полностью пустой до и после выполнения тестов.
Мое беспокойство по поводу предварительно заполненных данных в базе данных заключается в том, что невозможно обеспечить, чтобы данные содержались в хорошем состоянии. Сами тесты будут создавать, удалять и изменять данные в базе данных, поэтому я действительно не понимаю, как хорошо иметь данные в базе данных до того, как вы начнете тестировать.
Похоже, что лучшим способом тестирования функциональности базы данных были бы следующие настройки:
- На этапе «настройки» перед тем, как тест будет запущен, вы сначала усекаете все таблицы в базе данных.
- Затем вы вставляете все данные, необходимые для тестовых случаев, которые вы собираетесь запустить
- Затем вы запускаете и проверяете тестовые случаи
- Затем в фазе «разрыва» вы снова усекаете все таблицы в базе данных.
Я не вижу другого лучшего способа убедиться, что данные, с которыми вы тестируете, являются хорошим тестируемым тестом.
Я что-то здесь упускаю? Разве это не лучший способ проверить функциональность, связанную с базой данных? Есть ли какая-то польза от наличия предварительно заполненной базы данных, которая всегда существует в базе данных (даже до того, как вы начнете тестирование или после того, как тесты будут выполнены)? Любая помощь в идеях, чтобы объяснить мой процесс по-другому, чтобы лучше донести свою точку зрения, также была бы полезной (то есть, если моя точка зрения имеет свои достоинства).
Ответы:
Для меня модульные тесты не должны иметь дело с базой данных, интеграционные тесты имеют дело с базой данных.
Интеграционные тесты, которые работают с базой данных, на практике должны иметь пустую базу данных с подходом разрыва и разрыва, использование подхода, основанного на транзакциях, является довольно хорошим способом (т. Е. Создание транзакции при настройке и откат при разрыве).
То, что ваш друг говорит, что он хочет сделать, это проверить с точки зрения «регрессии», то есть иметь реальные данные там и посмотреть, как система реагирует, в конце концов, ни одна система не идеальна, и обычно где-то могут быть плохие данные, которые обеспечивают некоторые причуды к вашей доменной модели.
Ваши лучшие практики - это путь, и я склоняюсь к тому, чтобы найти сценарий для некорректных данных, написать интеграционный тест с настройкой и разорвать этот точный сценарий.
источник
integration tests
- что вы имеете в виду? Как я уже упоминал, модули, использующие базу данных, могут и должны быть протестированы с помощью модульных тестов. База данных может быть изменена вручную или заменена реализацией в памятиЕсли ваши тесты зависят от базы данных, то я думаю, что более важно, чтобы данные, о которых вы заботитесь, были в известном для тестирования состоянии, а не в пустой базе данных. Одной из мер хороших тестов является то, что каждый тест должен потерпеть неудачу по одной причине, и ни один другой тест не должен потерпеть неудачу по той же причине.
Итак, если ваше тестирование заботится о состоянии данных, затем переведите данные в это известное состояние и верните данные в это состояние после выполнения ваших тестов, чтобы ваши тесты были воспроизводимыми.
Если вы можете отделить свои тесты от состояния данных с помощью насмешек, то это тоже будет хорошо. Вы упоминаете, что проводите модульное / интеграционное тестирование, но, конечно, эти две вещи должны рассматриваться отдельно. Ваши модульные тесты должны быть отключены от базы данных, если это вообще возможно, и ваши интеграционные тесты должны тестироваться с базой данных в известном состоянии.
источник
Ну, я вижу одно преимущество в том, что у нас есть предварительно заполненная база данных: вам не нужно писать код, который будет вставлять нужные вам данные, поскольку они там есть. В противном случае есть только недостатки. Может быть, кто-то изменил тестовые данные в базе данных? Может быть, кто-то пытался обновить данные? Но хуже всего то, что один контрольный пример сильно испортил базу данных ... В итоге вы вручную воссоздаете всю базу данных несколько раз.
Вы правы в том, как должны быть написаны тесты, за исключением того, что я бы ничего не урезал:
Теперь этот сценарий отлично подходит для юнит-тестов. Когда нужны данные как для модульного, так и для интеграционного тестирования, я обнаружил, что одна большая фаза установки, общая для всех тестовых случаев (мы перегруппировали все «вставки» в один статический метод), также может работать очень хорошо. Это как нечто среднее между вашей идеей и идеей вашего друга. Единственным недостатком является то, что вы должны быть очень осторожны при добавлении некоторых новых данных, чтобы не разбивать существующие тестовые случаи (но если вы добавляете примерно две-три строки в таблицу, как мы, это не должно быть проблемой)
источник
Я думаю, вам нужно сузить пример со своим коллегой и выяснить, что именно они значат. Вы оба можете быть на одной странице.
Пример: проверка таблицы транзакций по счету
Добьетесь ли вы этого, выполнив шаги 1 и 2 или начав с базы данных, уже находящейся в этом состоянии (восстановить резервную копию?), Я не уверен, что это имеет значение. Ваша идея написания сценариев для меня упрощает управление любыми необходимыми изменениями (например, если вы забыли создать учетную запись администратора и нуждаетесь в ней для нового пользователя). Файлы сценариев легче поместить в систему контроля версий, чем некоторые резервные файлы. Это также зависит от того, распространяете ли вы это приложение.
источник
Чтобы нарисовать аспекты нескольких ответов вместе и добавить мой 2p ...
Примечание: мои комментарии касаются, в частности , тестирования базы данных , а не тестирования пользовательского интерфейса (хотя очевидно, что аналогичное применимо).
Базы данных так же нуждаются в тестировании, как и интерфейсные приложения, но, как правило, тестируются на основе «работает ли он с интерфейсом?» или «отчеты дают правильный результат?», который, по моему мнению, тестируется очень поздно в процессе разработки базы данных и не очень надежен.
У нас есть ряд клиентов, которые используют модульное / интеграционное / системное тестирование для своей базы данных хранилища данных в дополнение к обычному UAT / performance / et al. тесты. Они обнаружили, что с помощью непрерывной интеграции и автоматизированного тестирования они сталкиваются со многими проблемами, прежде чем переходить к традиционному UAT, что экономит время в UAT и увеличивает шансы на успех UAT.
Я уверен, что большинство согласится с тем, что к тестированию базы данных следует применять такую же строгость, как к тестированию внешнего интерфейса или отчета.
Ключевым моментом при тестировании является тестирование небольших простых объектов, обеспечивая их правильность, прежде чем переходить к сложным комбинациям объектов, обеспечивая их правильность, прежде чем перейти к более широкой системе.
Таким образом, давая некоторый контекст для моего ответа ...
Модульное тестирование
Преимущества этого состоят в том, что вы удаляете все внешние зависимости от теста и выполняете наименьшее количество тестов, чтобы доказать правильность. Очевидно, что эти тесты не могут быть запущены в производственной базе данных. Может случиться так, что есть несколько типов тестов, которые вы будете выполнять, в зависимости от типа устройства, включая:
(Блок) интеграционное тестирование
Я нашел этот пост SE полезным в разговоре о различных типах тестирования.
При переходе от модульных тестов к этим интеграционным тестам часто будет немного больше данных, чтобы протестировать более широкий спектр тестовых случаев. Очевидно, что эти тесты не могут быть запущены в производственной базе данных.
Затем он переходит к системному тестированию , тестированию системной интеграции (он же конец-2-end тестирование) с увеличением объемов данных и увеличением объема. Все эти тесты должны стать частью системы регрессионного тестирования. Некоторые из этих тестов могут быть выбраны пользователями для выполнения в рамках UAT, но UAT - это тесты, определенные пользователями , а не как они определены ИТ-отделом - обычная проблема!
Итак, теперь, когда я дал некоторый контекст, чтобы ответить на ваши актуальные вопросы
источник
Честно говоря, я думаю, что если вы проводите модульное тестирование без базы данных, примерно такой же, как у существующей производственной базы данных, у вас будет много вещей, которые пройдут тесты и потерпят неудачу в производстве для повышения производительности. Конечно, я против того, чтобы люди по этой причине тоже разрабатывали небольшую локальную базу данных.
И если код специфичен для данных, как вы можете эффективно протестировать его без данных? Вы не увидите, вернули ли запросы правильные результаты. Почему вы даже хотите рассмотреть возможность тестирования на пустой базе данных, все, что вам говорит, это если синтаксис правильный, а не запрос правильный. Это кажется близоруким для меня. Я видел слишком много вещей, которые запускаются и проходят тесты, которые категорически неверны. Разве вы не хотите найти это в модульном тестировании? Я делаю.
источник