Как моделировать DB для тестирования (Java)?
Когда вы печатаете какую-то переменную для javascript, лучше ее jsonify. Напишите шаблонный тег jsonify, затем используйте
{{value|jsonify}}
Шаблонные теги
from django.core.serializers import serialize
from django.db.models.query import QuerySet
import json
from django.template import Library
register = Library()
def jsonify(object):
if isinstance(object, QuerySet):
return serialize('json', object)
return json.dumps(object)
register.filter('jsonify', jsonify)
10 ответов
Для начала, используете ли вы какой-либо уровень ORM для доступа к БД?
Если нет: тогда то, о чем вы думаете, бесполезно. Какая польза от тестирования, если вы не уверены, что SQL, который вы запускаете, будет работать с вашей БД в производственной среде, поскольку в тестовых примерах вы используете что-то еще.
Если да: тогда вы можете посмотреть на различные указанные варианты.
Я согласен с банжолизмом. Создание изолированной среды разработки и тестирования должно быть приоритетом. Каждая система баз данных, которую я использовал, имеет либо открытый исходный код, либо бесплатную версию для разработчиков, которую вы можете установить на локальную рабочую станцию. Это позволяет вам разрабатывать на том же диалекте базы данных, что и в производственной среде, дает вам полный доступ администратора к базам данных для разработки и работает быстрее, чем использование удаленного сервера.
Прямо сейчас мы создаем тестовую среду базы данных. Мы считаем, что должны использовать реальную систему управления базами данных с смоделированными данными . Одна из проблем смоделированной СУБД состоит в том, что SQL никогда не становился полностью стандартом, поэтому искусственная среда тестирования должна точно поддерживать диалект нашей производственной базы данных. Другая проблема заключается в том, что мы широко используем ограничения значений столбцов, ограничения внешнего ключа и уникальные ограничения, и поскольку искусственный инструмент, вероятно, не будет их реализовывать, наши модульные тесты могут пройти, но наши системные тесты не пройдут, когда они впервые попадут в реальный ограничения. Если тесты занимают слишком много времени, это указывает на ошибку реализации, и мы должны настроить наши запросы (обычно наборы тестовых данных незначительны по сравнению с производственными).
Мы установили настоящую СУБД на каждую машину разработчика и на наш сервер непрерывной интеграции и тестирования (мы используем Hudson). Я не знаю, каковы ограничения вашей рабочей политики, но установить и использовать PostgreSQL, MySQL и Oracle XE довольно просто. Все они бесплатны для использования в целях разработки (даже Oracle XE), поэтому нет никаких рациональных причин запрещать их использование.
Ключевой вопрос заключается в том, как гарантировать, что ваши тесты всегда начинаются с базы данных в согласованном состоянии? Если бы все тесты были доступны только для чтения, проблем не было. Если бы вы могли разработать мутирующие тесты так, чтобы они всегда выполнялись в транзакциях, которые никогда не фиксируются, не проблема. Но обычно вам нужно беспокоиться об отмене обновлений. Для этого вы можете экспортировать начальное состояние в файл, а затем импортировать его обратно после тестирования (это делают команды оболочки Oracle exp и imp). Или можно использовать чекпоинт / откат. Но более элегантным способом является использование такого инструмента, как dbunit , который хорошо работает для нас.
Ключевым преимуществом этого является то, что мы выявляем гораздо больше ошибок заранее, где их гораздо легче исправить. и наше реальное тестирование системы не блокируется, пока разработчики лихорадочно пытаются отладить проблемы. Это означает, что мы создаем лучший код быстрее и с меньшими усилиями.
Если вы используете Oracle на работе, вы можете использовать функцию «Точка восстановления в базе данных Flashback», чтобы вернуть базу данных во время, предшествующее вашим тестам. Это удалит все изменения, которые вы лично внесли в БД.
См .:
https://docs.oracle.com/cd/E11882_01/backup.112/e10642/flashdb.htm#BRADV71000
Если вам нужна тестовая база данных для использования с Oracle production / work, а затем выполните поиск в базе данных XE Express Edition от Oracle. Это бесплатно для личного использования, размер базы данных не превышает 2 ГБ.
Я использовал Hypersonic для этой цели. По сути, это JAR-файл (чистая база данных Java в памяти), который вы можете запускать в собственной JVM или в своей собственной JVM, и пока он работает, у вас есть база данных. Затем вы останавливаете его, и ваша база данных исчезает. Я использовал это - пока - как чисто базу данных в памяти. При выполнении модульных тестов очень просто запускать и останавливать через Ant.
Java поставляется с Java DB .
Тем не менее, я бы не советовал использовать другой тип БД, отличный от того, что вы используете в производстве, если вы не используете ORM слой. В противном случае ваш SQL может быть не таким кроссплатформенным, как вы думаете.
Также проверьте DbUnit
Там Существует множество точек зрения на то, как тестировать точки интеграции, такие как соединение с базой данных через SQL. Мой личный набор правил, который мне понравился, выглядит следующим образом: Причина: для проверки большей части логики в системе лучше всего использовать фиктивную / заглушку вместо реальной базы данных, поскольку это проще. Причина 2: это значительно быстрее
2) Рассматривайте тесты для базы данных как интеграционные тесты, которые отделены от основной части модульных тестов и должны выполняться в установленной базе данных. Причина: Скорость и качество тестов
3) Каждому разработчику потребуется собственная отдельная база данных. Им потребуется автоматизированный способ обновления его структуры на основе изменений от их товарищей по команде и введения данных. См. Пункты 4 и 5.
4) Используйте инструмент вроде http://www.liquibase.org для управления обновлениями в структуре вашей базы данных. Причина: дает вам возможность изменять существующую структуру и продвигаться вперед в версиях
5) Используйте такой инструмент, как http://dbunit.sourceforge.net/ , для управления данными. Настройте файлы сценария (xml или XLS) для конкретных тестовых случаев и базовых данных и удалите только то, что необходимо для любого одного тестового примера. Причина: гораздо лучше, чем вставка и удаление данных вручную Причина 2: тестировщикам легче понять, как корректировать сценарии Причина 3: это быстрее выполняется
6) Вам нужны функциональные тесты, которые также имеют DBUnit, как данные сценария, но это гораздо большие наборы данных, которые выполняют всю систему. Это завершает этап объединения знаний, которые а) Запускаются модульные тесты, поэтому логика верна б) что тесты интеграции с базой данных выполняются и SQL верен в результате «и система в целом работает вместе как стек сверху вниз»
Эта комбинация хорошо служила мне до сих пор для достижения высокого качества тестирования и продукта, а также для поддержания скорости разработки модульных тестов и гибкости для изменение.
"Достаньте себе тестовую базу данных, насколько это сложно?" - Ну, на моем рабочем месте иметь личную тестовую БД практически невозможно. Вы должны использовать «общедоступную» базу данных, доступную для всех.
Похоже, у вас есть культурные проблемы на работе, которые мешают вам выполнять свою работу в полной мере, в зависимости от ваших способностей и возможностей. выгода от вашего продукта. Возможно, вы захотите что-то с этим сделать.
С другой стороны, если ваша схема базы данных находится под контролем версий, вы всегда можете иметь тестовую сборку, которая создает базу данных из схемы, заполняет ее тестовыми данными, запускает ваши тесты , собирает результаты и затем удаляет базу данных. Он будет существовать только на время испытаний. Это может быть новая база данных в существующей установке, если проблема с оборудованием. Это похоже на то, что мы делаем там, где я работаю.
Мы недавно перешли на JavaDB или Derby ], чтобы реализовать это. Derby 10.5.1.1 теперь реализует представление в памяти, поэтому он работает очень быстро, ему не нужно переходить на диск: Derby In Memory Primer
Мы разрабатываем наше приложение для работы на Oracle, PostgreSQL и Derby, поэтому мы не зайдем слишком далеко на какой-либо одной платформе, прежде чем обнаружим, что одна база данных поддерживает функцию, которую не имеют другие. т.
Попробуйте использовать derby. Он прост и портативен. С Hibernate ваше приложение становится гибким. Тестируйте на derby, а в продакшене используйте все, что вам нравится и чему вы доверяете.