Скажем, у меня есть struct
, который соответствует Equatable
для моей модели, что-то вроде этого:блок стратегия тестирования для соответствующей Equatable
struct Model: Equatable {
var a: Int = 0
var b: String = ""
}
func ==(lhs: Model, rhs: Model) -> Bool {
return lhs.a == rhs.a && lhs.b == rhs.b
}
Теперь я пишу несколько модульных тестов для этого. Что-то вроде:
func testModelsAreEqual() {
let model1 = Model()
let model2 = Model()
XCTAssertEqual(model1, model2)
}
func testModelsAreNotEqual1() {
let model1 = Model()
var model2 = Model()
model2.b = "hello world"
XCTAssertNotEqual(model1, model2)
}
func testModelsAreNotEqual2() {
let model1 = Model()
var model2 = Model()
model2.a = 1
XCTAssertNotEqual(model1, model2)
}
Но как я могу написать тест, который защитит меня от сценария, и другое свойство добавляется Model
без добавления в проверке почленно-равенства для ==
как:
struct Model: Equatable {
var a: Int = 0
var b: String = ""
var c: Double = 0
}
func ==(lhs: Model, rhs: Model) -> Bool {
return lhs.a == rhs.a && lhs.b == rhs.b
}
Где, очевидно, мои тесты все равно пройдут, хотя концептуально мой Equatable
не работает. Есть ли стратегия тестирования, которую я могу принять здесь, которая поможет предупредить меня об этой проблеме? Есть ли что-то, что я могу сделать с Swift's Mirror
и ограниченным отражением? Возможно Mirror.children.count
? Или у кого-то есть лучшее предложение?
Вы нашли лучшее, менее косвенное решение для этой проблемы? Очень просто сделать неправильный протокол для принятого типа неправильным, и его, вероятно, очень трудно заметить без надлежащих модульных тестов. – bartzy
К сожалению, я этого не делал. И, судя по некоторым другим дискуссиям, которые я видел в Интернете, нет никаких лучших идей. –