Продолжение протоколов…

Это продолжение предыдущей статьи

Сценарий 2:
Все мы работали над процессами входа или регистрации, выполняли сетевые вызовы и анализировали ответы. Давайте поговорим о валидаторе.

Примечание: Кстати, 2-й и 3-й пункты Это связаны, я дам вам знать, почему.

Делая запрос на вход в систему, мы сначала проверяем поля, и для этого мы обычно добавляем if else в действие, но это никак не может быть протестировано (написание тестовых случаев). Итак, вот концепция единой ответственности «S» от SOLID. Контроллер не несет ответственности за проверку каких-либо полей. Поэтому мы создадим для этого отдельный класс. И распределять ответственность.

Давайте начнем часть кодирования

protocol ValidatorType{
 func isValid() -> Bool
}
// Class Implementing type
class EmailValidator: ValidatorType{
 var value: String?
 init(value: String){
  self.value = value
 }
 func isValid() -> Bool {
// add condition
  return true
 }
}

Теперь давайте создадим для него модульный тест,

Now in this way any Field, The benefit is that you can create testcase for the function.
class MockValidator: ValidatorType{
var value: String? = abc
func isValid() -> Bool {
  guard let value = value else {
    return false
  }
   return value == "abc"
  }
}
// Testcase for success Scenario
func test_whenMockStringPassed_shouldReturnTrue() {
 let expectation = self.expectation(description: "Should return True")
 var expectedValue = "abc"
 XCTAssertEqual(validateField(type: MockValidator(value: expectedValue)), true)
 
 expectation.fulfill()
}

Это была небольшая демонстрация преимуществ протокола и варианта использования модульного теста. Есть несколько статей о валидаторах, которые вы можете проверить, и я также скоро напишу простую статью для валидатора.
Вы можете попробовать разными способами. Я также работал с сетевыми классами, которые будут в следующей статье.