DBMS в оперативной памяти для поблочного тестирования
Extjs использует шаблон MVC, поэтому вам не нужно копать измененные значения вручную. Ваши записи данных (чистые и грязные) находятся в хранилище, соединение управляется прокси. Сетка - это просто визуальный компонент для визуализации данных, а ее плагины помогают при изменении данных.
Не (повторно) создавать новый запрос внутри вашей функции, но скажите магазину выполнить эту работу:
handler: function () {
form.updateRecord();
form.hide();
grid.getStore().sync();
}
также укажите параметры прокси:
proxy: {
type: 'ajax',
batchActions: true,
url: './myownurl',
actionMethods: {
create: 'POST',
read: 'POST',
update: 'POST',
destroy: 'POST'
},
reader: {
type: 'json',
rootProperty: 'results'
},
writer: {
type: 'json',
root: 'data',
encode: true,
writeAllFields: true,
}
}
5 ответов
Учитывая, что Вы заявляете:
Я должен также упомянуть, что связал меня с TSQL, так как я только когда-либо собираюсь быть использованием платформы Microsoft.
Затем Используя SqlServer компактный Выпуск может работать хорошо на Ваши потребности. Это не будет работать полностью в памяти, но может работать в режиме только для чтения (где никакие редактирования не происходят с основным файлом базы данных, таким образом, это может использоваться несколькими тестами сразу),
Существует несколько глюков, никакие хранимые процедуры не поддерживаются, несколько типов данных должны быть переведены, и определенные типы данных имеют трудные пределы (особенно varchar, который может только перейти к 4 000 символов), Linq к Sql также правильно не поддерживается.
Тем не менее, я использовал SqlServer Компактный Выпуск в качестве почти полностью замена отбрасывания для надлежащей базы данных Sql Server с хорошими результатами.
Я слышал, что существует программное обеспечение для монтирования, электронный диск в окнах (не может помнить URL, извините).
Могло быть интересно создать тестовые базы данных по этому.
Я рекомендовал бы использовать ту же базу данных для Ваших модульных тестов что касается производства. Вам действительно не нужно некоторое странное различие, стреляющее Вам в ногу при отладке живой проблемы.
Если Вы взглянете на действительно большой комплект модульного теста для NHibernate, то Вы будете видеть, что он использует (находящийся на диске) SQL Server, и тестовый прогон удивительно быстро. Это является еще более впечатляющим, полагают, что существует намного больше создания таблицы / удаление, продолжающееся, чем средний набор модульных тестов, который не является тем, для чего оптимизирован SQL Server.
Я нашел, что SQLite наилучший вариант. Хотя, я использую nHibernate, но это - нулевая конфигурация, таким образом, только требуется секунда для установки. Хотя, действительно необходимо знать, что эти типы механизмов обычно испытывают недостаток в нескольких вещах, в которых Вы, возможно, нуждались бы (например, аварийные завершения SQLite, когда у Вас есть пробелы в именах таблиц при использовании поставщика ADO),
Предоставленный, @TopBanana прав относительно некоторых проблем с не использованием "фактической" базы данных. Однако RDBMS в оперативной памяти идеально подходит для тех видов тестов, которые Вы хотите запустить действительно быстро (например, тесты регистрации для возрастающего или сборок CI).
Другое огромное преимущество состоит в том, что Вы не должны волноваться об установке или разъединить. Это невероятно непроизводительно, чтобы иметь Ваш сбой регистрации, потому что разработчик A повредил Вашу dev базу данных ;-)
SQL Server является действительно узким местом для Ваших модульных тестов?
Я имею в виду:
- Вы представили свои модульные тесты (с чем-то как SQL Profiler). Они являются все медленными? Некоторые являются медленными? Почему?
- Ваши модульные тесты делают слишком много? Слишком тяжел код установки и разрушения?
- Если SQL является Вашим узким местом, Имейте Вас, рассмотрел платформу насмешки, таким образом, Вы дразните все свои вызовы SQL.