Как мне проверить метод isEqual типов объектов значений в BDD?

Question

Я новичок в BDD, даже для всего мира тестирования.

Я пытаюсь использовать методы BDD при написании простой библиотеки линейной алгебры в быстром. Таким образом, было бы много типов объектов значение как Matrix, Vector и т.д. При написании кода, я полагаю, мне еще нужно придерживаться принципа TDD (я прав?):

Не написав ни одной строки кода без провал попытка тест

чтобы реализовать тип объекта значения, мне нужно, чтобы он соответствовал Equatable протоколу и осуществлять его оператор ==. Это добавление кода, поэтому мне нужен провал. Как написать спецификацию для подобных сценариев?

Можно предложить некоторые подходы, как:

describe("Matrix") { 
    it("should be value object") { 
     let aMatrix = Matrix<Double>(rows: 3, cols:2) 
     let sameMatrix = Matrix<Double>(rows: 3, cols:2) 
     expect(sameMatrix) == aMatrix 
     let differentMatrix = Matrix<Double>(rows: 4, cols: 2) 
     expect(differentMatrix) != aMatrix 
    } 
} 

Это было бы некрасиво шаблонным по двум причинам:

1. Там может быть много типов объектов значения, и мне нужно повторить для всех из них
2. Может быть много случаев, из-за которых два объекта не равны. Например, взяв вышеприведенную спецификацию, выполнение теста ==, например return lhs.rows == rhs.rows, пройдет тест. Чтобы выявить эту «ошибку», мне нужно добавить еще одно ожидание, например expect(matrixWithDifferentColmunCount) != aMatrix. И снова это повторение повторяется для всех типов объектов значений.

Итак, как я должен испытать этот метод «isEqual» (или operator==) элегантно? или я не должен проверять его вообще?

---

Я использую быстрый и Quick для среды тестирования. Quick обеспечивает механизм, называемый SharedExample для уменьшения шаблонов. Но так как swift - это статический язык ввода текста, а общий пример Quick не поддерживает generics, я не могу напрямую использовать общий пример для проверки объектов значений.

Я придумал workaround, но не считаю его элегантным.

Answer 1

Elegance является врагом испытательных комплексов. Испытательные комплекты скучны. Набор тестов повторяется. Испытательные комплекты не являются «СУХОЙ». Чем более умны ваши тестовые комплекты, тем больше вы пытаетесь избежать шаблонов, тем больше вы тестируете свою тестовую инфраструктуру вместо своего кода.

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

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

В качестве побочного примечания ваш тест не проверяет, что он говорит. Вы тестируете, что идентичные конструкторы создают равные объекты, а неидентичные конструкторы создают неравные объекты (что в принципе является двумя тестами). Это вовсе не проверяет, что это объект ценности (хотя это очень хорошо, что нужно проверить). Это не огромная сделка.Не позволяйте философии тестирования мешать полезному тестированию; но хорошо, чтобы ваши названия соответствовали вашим намерениям тестирования.