Как я могу издеваться над ресурсами?

Question

В моем приложении у меня есть класс, который инкапсулирует Service и имеет методы, возвращающие ресурсы и запросы. В моих тестах я хочу издеваться над успехами/неудачами для запросов и ресурсов без каких-либо реальных сетевых вызовов.
Поскольку Request является протоколом, это легко сделать это, возвращая пользовательскую реализацию, которая просто вызывает onSuccess, onFailure и т.д.

Однако, это не так просто для методов, возвращающих Resource, поскольку Resource является окончательным класс, а не протокол.
Я хочу создать mock Resource, который не выполняет никаких реальных сетевых запросов, когда вызывается load() и предоставляет какой-то способ подделать успех/сбой, который вызывает наблюдателей, добавленных в Resource.

Есть ли способ сделать это на данный момент?

Answer 1

У вас есть несколько вариантов:

Сто NetworkingProvider

Создать свой сервис с помощью пользовательского NetworkingProvider реализации.

// App 

var myAppNetworkingProvider: NetworkingProviderConvertible = 
    URLSessionConfiguration.ephemeral // Siesta default 
... 
Service(baseURL: "...", networking: myAppNetworkingProvider) 

// Tests 

myAppNetworkingProvider = NetworkStub() 

Ваш StubbedNetworkingProvider может возвращать один жестко или матч на URLRequest, если вы хотите окурок несколько ответов на один раз.

Это лучший вариант для большинства приложений. Вы можете увидеть его пример в Siesta’s own performance tests. Это просто, быстро и дает мелкозернистый контроль, но все же позволяет вам протестировать с реалистичным поведением Siesta.

тупиковой сети

Siesta работает с сетевыми гася библиотек как OHHTTPStubs, Mockingjay и Nocilla. (Siesta сама использует Nocilla для собственных внутренних регрессионных тестов, хотя библиотека имеет внутренние условия гонки и не особенно хорошо поддерживается на момент написания этой статьи, поэтому я не могу ее полностью рекомендовать).

Съемка самой сети имеет преимущество тестирования полного взаимодействия вашего приложения с базовым сетевым API. Этот подход может быть лучше всего для полнофункциональных тестов интеграции, особенно если вы хотите записывать и воспроизводить ответы от реального API.

Протокол пользовательских ресурсов

Поскольку Swift поддерживает retroactive modeling, Resource не должны быть (или реализация) проверяемый протокол. Вы можете создать собственное:

protocol ResourceProtocol { 
    // Resource methods your app uses 
} 

// No new methods; just adding conformance 
extension Resource: ResourceProtocol { } 

Это похоже на то, что вы ищете в своем оригинальном вопросе. Тем не менее, я не особо рекомендую:

• Это самый сложный в реализации - и наиболее подверженный ошибкам. Вы удивительно трудно точно имитировать все поведение Сиесты. Поверьте мне: API ресурсов кажется сначала невиновным, но вы обнаружите, что переопределите половину библиотеки, если попытаетесь реализовать все это приложение таким образом.
• Вероятно, упустите проблемы и не поймайте регрессии.Многие из опасных мест, использующих Siesta, связаны с точной последовательностью вызовов: какие события происходят и в каком порядке, что происходит сразу же после следующего поворота основного цикла запуска, какие отношения наблюдателя/владельца делают или не делают создавать циклы сохранения и т. д. Вам придется делать предположения обо всех этих вещах, и вы в конечном итоге будете тестировать свой код против своих предположений, а не против реального поведения библиотеки.

Короче говоря, по сравнению с другими подходами это более высокое усилие для более низкого значения. Это, конечно, не эффективный способ проведения регрессионного тестирования.

При этом, если вы придерживаетесь философии модульного тестирования пуриста «не тестируйте границы», то это способ сделать это.

Answer 2

Я нахожусь в процессе написания приложения, которое использует Siesta, и я использовал URLMock для издевательства сетевых запросов, которые делает Siesta. Я был доволен результатом (он просто делает то, что я хочу, без особых проблем), но я уверен, что другие библиотеки тоже будут работать. Я рекомендую работать с сетевой издевательской библиотекой, у них есть функции, о которых вы, возможно, и не подумали сразу, например, настроить ее для возврата ошибки, если тест вызывает неожиданные сетевые запросы.

Вот как я установка URLMock работать с Siesta:

override class func setUp() { 
    super.setUp() 
    UMKMockURLProtocol.enable() 
    UMKMockURLProtocol.setVerificationEnabled(true) 
} 

override class func tearDown() { 
    UMKMockURLProtocol.setVerificationEnabled(false) 
    UMKMockURLProtocol.disable() 
    super.tearDown() 
} 

override func setUp() { 
    super.setUp() 
    // Put setup code here. This method is called before the invocation of each test method in the class. 
    UMKMockURLProtocol.reset() 
    let testConfig = URLSessionConfiguration.ephemeral 
    testConfig.protocolClasses = [UMKMockURLProtocol.self] 
    service = Service(baseURL: expectedV2Host, useDefaultTransformers: true, networking: testConfig) 
}