Как я могу протестировать базовые службы на основе ngResource?

У меня прилично большое количество базовых услуг, большинство из которых определяются точно так же:Как я могу протестировать базовые службы на основе ngResource?

app.factory('Group',['$resource',function (resource) { 
    return resource('/api/group/:group', {group:'@id'},{}); 
}]);

И так далее. Очень немногие немного отличаются друг от друга и имеют либо уникальные свойства, например. User может также иметь активацию:

app.factory('User',['$resource',function (resource) { 
    return resource('/api/user/:user', {user:'@id'},{ 
    activate: {method:'PUT', url:'/api/activate/:user'} 
    }); 
}]);

Или заставить некоторые ожидаемый ответ, например, GET может дать массив:

app.factory('GroupMembers',['$resource',function (resource) { 
    return resource('/api/group/:group/members', {group:'@id'},{ 
     get: {method:"get",isArray:true}   
    }); 
}]);

Я ищу здравый путь модульного тестирование этих. Похоже, что использование $httpBackend для захвата всех запросов - это чересчур избыток, но укупорка в $resource может быть недооценена. Будет ли мне лучше обслуживать любой из этих подходов? Или, возможно, какой-либо набор функций тестов, который выполняет все команды get/put/post/patch/delete/query и переопределяет для конкретных случаев, таких как добавленный activate для User или специальный get для GroupMembers?

источник

2014-10-12 deitch

Hello @deitch. Я думаю, вам нужно будет тестировать свои контроллеры и другие службы в зависимости от ресурсов. ИМО не имеет смысла испытывать такие сервисы, как служба группы, поскольку это в основном тестирование рамки, которую вы не хотите делать. Если вы тестируете более высокоуровневые сервисы, я думаю, что вы можете просто издеваться над этим ресурсом, но я не уверен, что это лучший подход. Вот почему я не пишу ответа :). –

@MiroslavNedyalkov Вы должны сказать это как ответ. Услуги, основанные на $ ресурсах в этом вопросе, не нуждаются в проверке, по какой именно причине вы даете. Я обычно создаю простой mock-ресурс, и в своем модульном тесте для контроллеров я использую spyOn() для проверки правильности использования ресурса $. –

@SunilD. что вы имеете в виду? Я понимаю, что вам не нужно тестировать '$ resource' - просто доверяйте фреймворку и его тесты, но как насчет остальных? Вы используете тесты контроллера для использования ресурсов? – deitch

IMO, вы не должны тестировать свои ресурсы, так как это будет тестирование самой структуры. Вы должны проверить свои другие службы и контроллеры, которые используют ресурсы. Для таких тестов оба подхода (издевательства над ресурсами или $ httpBackend) будут выполнять эту работу, поэтому вам просто нужно выбрать более прямой вариант для вас. Я бы проголосовал за предложение Сунил Д., чтобы высмеять ресурс, поскольку он изолирует его от целевой цели.

Если вы считаете, что вам нужно проверить, объявили ли вы свойство услуги, вы можете написать очень простые тесты только для ресурсов, издевательствующих над $ httpBackend, но я бы не тратил свое время на такие тесты, как критическая часть кода В рамках.

источник

2014-10-13 05:26:33

Я думаю, что это является сердцем философского вопроса здесь: если мы объявляем основные ресурсы, нам нужно их протестировать? Лично я бы хотел, чтобы у меня было меньше в первую очередь, но это результат использования бизнес-объектов, а не технической архитектуры. Как бы вы пишете эти простые тесты? – deitch

Как я могу протестировать базовые службы на основе ngResource?

ответ

Смежные вопросы