Тестирование на ветер

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

Моя вторая проблема заключается в том, как я могу проверить свои вызовы на сервер. Я видел некоторую информацию на странице бриза о тестировании. Также я видел пример DocCode. Но я хотел бы узнать больше о том, как я могу это сделать.

Мои вопросы:

Что мне нужно проверить при звонках?
Я бы хотел проверить это, подражая бэкэнду. Является ли это возможным? Любой пример?
Любые советы или комментарии были бы замечательными.

Ответ 1

Ух ты... это большой вопрос!

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

Я предполагаю, что вы довольно новичок в тестировании JavaScript. Если вы видели DocCode, вы знаете, что здесь мы используем QUnit. Многие предпочитают Жасмин, Мокку или что-то еще; Я могу говорить только с QUitit.

Первый шаг - узнать QUnit. Это не сложно. QUnit собственное введение. Мне нравится слайд-панель Ben Alhman.

Затем я практиковал с небольшими тестами вашей бизнес-логики, которые НЕ проходят по проводу. Может быть любая интересная логика в ViewModel или, возможно, некоторое вычисляемое свойство в объекте model (entity).

Вы можете легко протестировать взаимодействие VM с "DataContext", не обойдя провод. Создайте "FakeDataContext" и добавьте это в свои тесты вместо реального. В качестве альтернативы вы можете "патч обезьяны - настоящий "DataContext" в стратегических местах, которые превращают его в подделку.

При подделке DataContext я считаю полезным использовать способность Breeze ограничить запросы локальным кешем. Локальный кеш служит в качестве суррогата в памяти для данных, которые в противном случае были бы получены с сервера.

Это может быть так же просто, как установка FetchStrategy менеджера по умолчанию QueryOptions... возможно, как это

var queryOptions = new QueryOptions({ 
    mergeStrategy: MergeStrategy.PreserveChanges, 
    fetchStrategy: FetchStrategy.FromCache 
});

var entityManager = new EntityManager({ 
    serviceName: "yourEndpoint", 
    queryOptions: queryOptions
});

Теперь ваши запросы будут направлены в кеш (если у них нет явного QueryStrategy).

Теперь сделайте это полезным, заполнив кэш тестовыми данными. В DocCode имеется множество примеров фальшивых сущностей. Вот пример подделанного клиента:

   var testCustomer = manager.createEntity('Customer', {
       // test values
       CustomerID: testCustomerID,
       CompanyName: testCustomerName,
       ...
    }, breeze.EntityState.Unchanged); // as if fetched from the database

Если мне нужны одни и те же данные теста, я пишу "Мать данных", которая заполняет EntityManager тестовыми данными для меня.

Я могу сделать много испытаний таким образом, не ударяя по серверу. Все время я работаю с объектами Breeze в JavaScript... так же, как и в производственном коде. Мне не нужно изучать насмешливую библиотеку или вводить другой инструмент.

Другой подход - более жесткий, более низкий, но более мощный - это заменить Breeze адаптер AJAX по умолчанию с подделкой, которая возвращает тестовые значения JSON, как если бы они пришли с сервера. Вы можете использовать такой инструмент, как Fiddler, чтобы сделать поддельный JSON из мгновенных снимков полезной нагрузки. Вы также можете использовать этот трюк для моделирования поведения сохранения на стороне сервера.

Обновление 3 мая 2013 г.

Пример DocCode включает новый TestAjaxAdapter для моделирования ответов сервера, как я только что описал. Проверьте testAjaxAdapter.js и посмотрите, как его использовать в testAjaxAdapterTests.js. Эта конкретная версия DocCode доступна только на GitHub, но она будет официально опубликована в выпуске сразу после v.1.3.2.

... конец обновления; вернуться к исходному сообщению...

Поддельные потоки JSON внутри вашего поддельного адаптера AJAX кажутся слишком большим из PITA? Выполните безумные навыки Бриза и напишите пользовательский JsonResultsAdapter, чтобы создать эти подделки. Попросите ваш поддельный адаптер AJAX вернуть пустой массив для каждого запроса запроса. Затем вы можете делать все, что хотите, в методах extractData и visitNode вашего JsonResultsAdapter.

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

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

Обновление 30 апреля 2013 г.

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

Так верно. Теперь я не сторонник в этом вопросе. Я не против попадания сервера на метаданные в верхней части тестового модуля... ровно один раз... и затем запускаю остальные мои тесты, не переходя на сервер для метаданных. Но если вы пурист или просто не хотите этого делать, вы можете записать метаданные на стороне сервера в файл JavaScript на сервере и загрузить статический текст script на странице HTML-теста тестового запуска, как и любой другой script.

В качестве примера этого метода рассмотрим App_Data/WriteMetadataScriptFiles.cs, который генерирует файл JavaScript для модели Northwind в предстоящей (позже на этой неделе) версии v.2.3.2 DocCode. Тесты DocCode динамически загружают файлы JavaScript с помощью require.js. В тестовом файле metadataTests.js показано, как загрузить сгенерированный файл northwindMetadata.js с требованием. Вам не обязательно быть умным, если вы не используете require.js.

Примечание для себя: напишите несколько примеров, иллюстрирующих эти методы.